什么是REST( REpresentational State Transfer)

REST是代表状态转移( REpresentational State Transfer)的缩写。 它是分布式超媒体系统的体系结构样式，由Roy Fielding于2000年在他的著名论文中首次提出。

与任何其他架构样式一样，REST还具有自己的6个指导约束，如果需要将接口称为RESTful，则必须满足这些约束。 这些原则在下面列出。

REST指导原则

1. 客户端-服务器 —— 通过将用户界面问题与数据存储问题分开，我们提高了用户界面在多个平台上的可移植性，并通过简化服务器组件来提高可伸缩性。
2. 无状态 —— 从客户端到服务器的每个请求都必须包含理解该请求所需的所有信息，并且不能利用服务器上存储的任何上下文。 因此，会话状态完全保留在客户端上。
3. 可缓存 —— 缓存约束要求对请求的响应中的数据被隐式或显式标记为可缓存或不可缓存。 如果响应是可缓存的，则授予客户端缓存以将响应数据重新用于以后的等效请求的权限。
4. 统一的接口 —— 通过将通用的软件工程原理应用于组件接口，可以简化整个系统架构，并提高交互的可见性。 为了获得统一的接口，需要多个体系结构约束来指导组件的行为。 REST由四个接口约束定义：资源标识； 通过表述操纵资源； 自我描述的信息； 并且，超媒体作为应用程序状态的引擎。
5. 分层系统 —— 分层系统样式允许通过限制组件的行为来使体系结构由层次结构层组成，从而使每个组件都无法“看到”与它们交互的直接层。
6. 可定制代码（可选）–—— REST允许通过以applet或脚本的形式下载并执行代码来扩展客户端功能。 通过减少预先实现的功能数量，简化了客户端。

资源

REST中信息的关键抽象是一个资源。 可以命名的任何信息都可以是资源：文档或图像，临时服务，其他资源的集合，非虚拟对象（例如人）等。 REST使用资源标识符来标识组件之间交互中涉及的特定资源。

资源在任何特定时间戳下的状态称为资源表示。 表示形式由数据，描述数据的元数据和超媒体链接组成，这些链接是帮助客户端转移到下一个状态所需的。

表示形式的数据格式称为媒体类型。 媒体类型标识一个规范，该规范定义了如何处理表示形式。 真正的RESTful API看起来像超文本。 每个可寻址的信息单元都携带一个地址，该地址可以是显式的（例如，链接和id属性），也可以是隐式的（例如，从媒体类型定义和表示结构派生）。

根据罗伊·菲尔丁（Roy Fielding）的说法：

超文本（或超媒体）是指信息和控件的同时呈现，以便信息成为用户（或机器人）通过其获得选择并选择动作的能力。 请记住，浏览器上的超文本不需要是HTML（或XML或JSON）。 当机器了解数据格式和关系类型时，它们可以跟随链接。

此外，资源表示应该是自我描述的：客户端不需要知道资源是雇员还是设备。 它应该基于与资源关联的媒体类型进行操作。 因此，在实践中，您最终将创建许多自定义媒体类型-通常是与一种资源关联的一种媒体类型。

每种媒体类型都定义一个默认处理模型。 例如，HTML定义了超文本的呈现过程以及关于每个元素的浏览器行为。 它与资源方法GET / PUT / POST / DELETE / ...无关，除了某些媒体类型元素将定义一个过程模型，就像“具有href属性的锚点元素创建一个超文本链接，该超文本链接在被选择时， 在与CDATA编码的href属性相对应的URI上调用request请求（GET）。”

资源方法

与REST相关的另一重要事项是用于执行所需转换的资源方法。 许多人错误地将资源方法与HTTP GET / PUT / POST / DELETE方法相关联。

罗伊·菲尔丁（Roy Fielding）从未提及过关于在哪种条件下使用哪种方法的任何建议。 他强调的只是它应该是统一的界面。 如果您决定使用HTTP POST来更新资源-而不是大多数人建议使用HTTP PUT——这样也是可以的，并且应用程序界面将是RESTful的。

理想情况下，更改资源状态所需的应是该资源的响应API的一部分-包括方法以及它们将以何种状态离开表示形式。

REST API 进入之前应该没有其他任何先前知识，除了初始URI（书签）和适用于目标受众的标准媒体类型集（即可能会被使用该API的任何客户端所期望的标准媒体类型）外。 从那时起，所有应用程序状态转换必须由客户端选择服务器提供的选择来驱动，这些选择出现在接收到的表示中或由用户对这些表示的操纵来暗示。 迁移可以由客户端对媒体类型和资源通信机制的了解来确定（或受其限制），这两者都可以即时（例如，按需编码）进行改进。[此处的失败表示带外信息正在驱动交互，而不是超文本。

在构建RESTful API时会帮助您的另一件事是，基于查询的API结果应该由带有摘要信息的链接列表来表示，而不是由原始资源表示形式的数组来表示，因为查询不能替代资源标识。

REST和HTTP不一样！

许多人喜欢将HTTP与REST进行比较。 REST和HTTP不相同。

REST != HTTP

但是，由于REST还打算使Web（互联网）更加精简和标准，因此他主张更严格地使用REST原理。 这就是人们尝试将REST与网络（HTTP）进行比较的地方。 罗伊·菲尔德（Roy fieldd）在其论文中，没有提到任何实现指令——包括任何协议首选项和HTTP。 到现在为止，您遵守REST的6项指导原则，您可以将界面称为RESTful。

简而言之，在REST体系结构样式中，数据和功能被视为资源，并且可以使用统一资源标识符（URI）进行访问。 通过使用一组简单的，定义明确的操作对资源进行操作。 客户端和服务器通过使用标准化的接口和协议（通常为HTTP）来交换资源的表示形式。

资源与它们的表示分离，因此可以以多种格式访问其内容，例如HTML，XML，纯文本，PDF，JPEG，JSON等。 有关资源的元数据可用并用于控制缓存，检测传输错误，协商适当的表示格式以及执行身份验证或访问控制。 最重要的是，与资源的每次交互都是无状态的。

所有这些原则都帮助RESTful应用程序变得简单，轻巧和快速。

参考文献：

http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven
http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm