05. 编码规约与协作
编码规约与协作
设计约定
本节分为两个部分：服务器端和客户端体系结构服务器端由
Server-side
-
#REST：服务器应用程序遵循
REST 原则，即，它公开了对坐在浏览器前的用户有意义的一组资源，每个资源都有自己的URI ，处理请求所需的所有信息都包含在请求本身中，HTTP 方法根据其定义使用，资源状态由服务器维护（无状态通信） 。 -
#APPLICATION-LOGIC：所有的应用逻辑应该放在服务端。
-
#HTTP：客户端通过
RESTful HTTP 请求与服务器交互。 -
#LINK：用户必须能够链接到特定信息，例如 通过从浏览器的地址栏中复制地址并将其粘贴到电子邮件中，创建书签或使用任何更高级的方式共享
URI 。 -
#NON-BROWSER：必须有可能通过浏览器以外的用户代理使用服务器的逻辑，例如浏览器。命令行客户端，例如
curl 或wget 。 -
#SHOULD-FORMATS：资源具有其他格式的其他表示形式，例如
JSON 和/ 或XML 。 -
#AUTH：所有经过身份验证的通信都依赖于
HTTP 基本或摘要身份验证，通常与SSL 结合使用，可能还与客户端证书结合使用。或者，由于浏览器本地身份验证的局限性（例如，不注销，不设置样式） ，可以将基于表单的身份验证与Cookie 结合使用。如果使用了Cookie ，则它们应包括服务器处理它们所需的所有状态，并且应支持另一种身份验证机制以进行非浏览器访问。 -
#COOKIES：
Cookies 不得用于除了身份验证，用户跟踪或CSRF 保护等安全目的的场景。 -
#SESSION：可能没有任何会话状态超出对认证信息进行简单算法验证所需的状态。
-
#BROWSER-CONTROLS：浏览器控件（例如后退，前进和刷新按钮）必须按预期工作。即 后退按钮应该将用户带到他们希望去的地方（他们使用的最后一个有意义的资源
） 。浏览器刷新不应导致重新呈现登录名或主页而不是用户正在查看的页面，也不应引起（对于用户）关于想要再次提交相同数据的意外问题（当用户不希望重新提交时）记得提交任何数据，表明滥用了POST 动词） 。
Client-side
-
#POSH：服务器返回与布局信息和客户端行为无关的结构化语义
HTML 标记。 -
#ACCESSIBILITY：必须使用屏幕阅读器等辅助工具来访问每个页面的信息和功能。
-
#IDIOMATIC-CSS：
CSS 用于格式化和布局。这是按照逐步增强的原则完成的，例如允许不具备CSS3 功能的浏览器仍可以使用基于CSS3 的网站。 -
#UNOBTRUSIVE-JAVASCRIPT：根据渐进增强的原则，如果禁用了
JavaScript ，则不加干扰地使用JavaScript ，并且该应用程序仍然可以使用（尽管可用性和便利性有所降低） 。 -
#NO-DUPLICATION：不得在客户端（JavaScript）和服务器上冗余实现相同的功能。因此，由于应用程序逻辑要求，应用程序逻辑不得驻留在客户端。
-
#KNOW-STRUCTURE：服务器代码可能不“知道”客户端代码生成的
HTML 结构（超出CSS ） ，反之亦然。服务器为初始化上述客户端功能而生成的一些定义良好的HTML 结构除外。 -
#STATIC-ASSETS：所有
JavaScript 代码和CSS 代码必须是静态的，并且不能由服务器以特定于请求资源的形式动态生成。 （请注意，这并不禁止使用诸如CoffeeScript 或LESS 之类的预处理器，因为通常会将相应的代码作为发布过程的一部分进行预编译。 ） -
#HISTORY API：客户端的
JavaScript 触发的任何动态路由或URI 状态修改都应使用HTML5 历史记录API 。