05.编码规约与协作
编码规约与协作
设计约定
Web 应用程序的体系结构受框架开发人员做出的隐式和显式设计决策的很大影响有时，这些决策会被有意识地接受为符合预期的总体系统架构但是，更经常地接受它们只是因为开发人员认为他们体现了开发实践的最新水平。
本节分为两个部分：服务器端和客户端体系结构服务器端由 RESTful 后端组成，这些后端服务于人类可读的内容以及公共或内部的机器对机器通信服务客户端基于渐进增强的原则，致力于 JavaScript 和 CSS 的可持续和可维护使用几乎每一种基本的网络技术都追求这种技术，例如 HTML 或 HTTP 客户端和服务器在很大程度上是相互独立的，但又相互补充。
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。