什么是REST

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上调用检索请求（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与Web（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