【译】设计REST的6个约束

转自：http://www.imooc.com/article/19451

wiki：https://en.wikipedia.org/wiki/Representational_state_transfer#Client-server

定义个一个RESTful系统的时候应该遵循6个约束。
它们限制了服务端只能遵循这些约束来处理和响应客户端请求，但是遵循这些约束服务也可以获取理想的非函数化的属性，例如性能、可伸缩、简单程度、可变能力、可见度、灵活性、可信度。
如果任何一个服务违背了其中一个原则，将不能被称作RESTful系统。
标准的REST约束如下：

客户端-服务器

参考内容：客户端-服务器模型

第一个约束是基于客户端-服务器架构背后的原则——关注点分离。
通过分离用户界面和数据存储这两个关注点，提高了用户界面跨平台的可能性，通过简化服务器组件提高了其可伸缩性。
这种分离对于Web来说更加重要的意义是，它使得组件能够进行独立修改和扩展，从而能够支持大量组织的网络化需求。

无状态

参考内容：无状态协议

客户端-服务器通信的一个制约条件就是服务端无法存储客户端的上下文执行环境。
从任何客户端发出的每个请求都包含了服务端所必要的信息，但是会话状态仍留在客户端。
然而在服务端会话状态可以轻松实现跨服务调用，例如利用数据库做持久化来保存一段时间内的身份认证信息。
客户端开始发送请求时，它已准备好过渡到一个新的状态。当一个或多个请求正在发送时，客户端处于过渡状态。
每个应用程序状态的表示包含可在下一次客户端选择发起一个新的状态过渡使用的链接。

可缓存

参考内容：网页缓存

互联网中的客户端和中间层服务器可以缓存响应。
因此响应必须直接或间接定义自身是否可被缓存，以免客户端使用过期的响应数据来发送其它请求。
良好的缓存策略可以有效减少客户端-服务器之间的交互，从而进一步提高系统的可伸缩性和性能。

分层系统

参考内容：分层系统

客户端通常无法判断它是否是直接连接到后端服务器，还是中间服务器。
中间服务器可通过启用负载平衡，并通过提供共享高速缓存来提高系统的可扩展性。
当然也可以强制执行安全政策。

按需代码（可选）

参考内容：客户端脚本

服务端可以通过传递可执行代码临时为客户端扩展或自定义功能。
这方面的例子包括可编译的组件如Java applets和客户机端脚本如JavaScript。

统一的接口

统一接口约束是设计任何REST服务的基础。
它简化和解耦的架构，使得每个部分可以独立被修改。这个统一的接口包含了四个约束：

资源的标识

各种资源都在请求中被确定，例如在使用URI的Web REST系统中，资源本身就表明它们想要被返回给客户端的格式。
例如服务端可以从它的数据库发送HTML，XML或JSON格式的数据，即使这些都不是服务端的内部数据格式。

通过表述来操作资源

当一个客户端持有一种资源的表述时，包括任何关联的元数据，它都有足够的信息来修改或删除该资源。

自描述的消息

每条信息都包含足够的信息来描述如何处理消息本身。
例如，一个网络媒体类型本身就定义了能运行该媒体的解析器（以前被称为MIME类型）。

超媒体作为应用程序状态的引擎（HATEOAS）

已经初始化URI的REST客户端应用，应该就像人们访问了一个Web网站主页一样，能够使用服务器提供的动态链接，请求它所需的资源和进行所需的操作。
处理客户端访问时，服务端将响应内容也包括当前可用的其它行为的超链接。
没有必要对REST服务的结构或动态信息进行硬编码来响应客户端客户端。

相关标签： 设计

作者： 亚里士朱德 
链接：http://www.imooc.com/article/19451
来源：慕课网