什么是REST
REST是REpresentational State Transfer表述性状态转移 的首字母缩写。它是分布式超媒体系统的架构风格，最初由Roy Fielding在2000年的着名论文中提出。
什么是RESTful：
REST-ful,其中ful代表形容词，如helpful,powerful。这类形容词意为"full of,having the quality of"。多加在名词之后表示“充满...的、易于...、可...的、富有...的、具有...的”的意思，是最常用的形容词后缀，反义词后缀是-less。
RESTful 就代表满足REST原则的。
与任何其他架构风格一样，REST也有自己的6个引导约束，如果接口需要被称为RESTful，则必须满足这些约束。这些原则如下。
REST的指导原则
- 客户端 - 服务器 - 通过将用户接口问题与数据存储问题分开，我们通过简化服务器组件来提高跨多个平台的用户接口的可移植性并提高可伸缩性。
- 无状态 - 从客户端到服务器的每个请求都必须包含理解请求所需的所有信息，并且不能利用服务器上任何存储的上下文。因此，会话状态完全保留在客户端上。
- 可缓存 - 缓存约束要求将对请求的响应中的数据隐式或显式标记为可缓存或不可缓存。如果响应是可缓存的，则客户端缓存有权重用该响应数据以用于以后的等效请求。
- 统一接口 - 通过将通用性的软件工程原理应用于组件接口，简化了整个系统架构，提高了交互的可见性。为了获得统一的接口，需要多个架构约束来指导组件的行为。REST由四个接口约束定义：资源识别; 通过陈述来处理资源; 自我描述性的信息; 并且，超媒体作为应用程序状态的引擎。
- 分层系统 - 分层系统风格允许通过约束组件行为来使体系结构由分层层组成，这样每个组件都不能“看到”超出与它们交互的直接层。
- 按需编码（可选） - REST允许通过以小程序或脚本的形式下载和执行代码来扩展客户端功能。这通过减少预先实现所需的功能数量来简化客户端。
REST和HTTP不一样!!
很多人更喜欢将HTTP与REST进行比较。REST和HTTP不一样。
REST！= HTTP
但是，由于REST还打算使web（互联网）更加简化和标准化，他主张更严格地使用REST原则。这就是人们试图开始将REST与网络（HTTP）进行比较的地方。Roy fielding在他的论文中没有提到任何实现指令 - 包括任何协议首选项和HTTP。到时候，您正在遵循REST的6个指导原则，您可以将您的接口称为RESTful。
简而言之，在REST架构风格中，数据和功能被视为资源，并使用统一资源标识符（URI）进行访问。通过使用一组简单，定义明确的操作来执行资源。客户端和服务器通过使用标准化接口和协议（通常是HTTP）来交换资源的表示。
资源与其表示分离，以便可以以各种格式访问其内容，例如HTML，XML，纯文本，PDF，JPEG，JSON等。例如，可以使用和使用关于资源的元数据来控制高速缓存，检测传输错误，协商适当的表示格式，以及执行认证或访问控制。最重要的是，与资源的每次交互都是无状态的。
所有这些原则都有助于RESTful应用程序简单，轻量和快速。
幂等REST API
在REST API的上下文中，当生成多个相同的请求与生成单个请求具有相同的效果时 - 然后该REST API称为幂等。
设计REST API时，必须意识到API使用者可能会犯错误。他们可以编写客户端代码，以便可以存在重复请求。这些重复请求可能是无意的以及有意的一些时间（例如由于超时或网络问题）。您必须以这样的方式设计容错API，使重复请求不会使系统不稳定。
幂等HTTP方法是一种HTTP方法，可以多次调用而不会产生不同的结果。如果只调用一次或十次调用该方法，则无关紧要。结果应该是一样的。它本质上意味着成功执行请求的结果与其执行次数无关。例如，在算术中，向数字加零是幂等操作。
如果您在设计API时遵循REST原则，那么您将拥有用于GET，PUT，DELETE，HEAD，OPTIONS和TRACE HTTP方法的自动幂等REST API。只有POSTAPI不是幂等的。
POST不是幂等的。GET，PUT，DELETE，HEAD，OPTIONS和TRACE是幂等。
让我们分析一下HTTP方法如何最终成为幂等 - 任何POST不是为什么。
HTTP POST
通常 - 不一定 - 使用POSTAPI在服务器上创建新资源。因此，当您调用相同的POST请求N次时，您将在服务器上拥有N个新资源。因此，POST不是幂等的。
HTTP GET，HEAD，OPTIONS和TRACE
GET，HEAD，OPTIONS和TRACE方法永远不会改变服务器上的资源状态。它们纯粹用于在那个时间点检索资源表示或元数据。因此，调用多个请求将不会在服务器上进行任何写操作，因此GET，HEAD，OPTIONS和TRACE是幂等的。
HTTP PUT
通常 - 不一定 - 使用PUTAPI来更新资源状态。如果您调用PUTAPI N次，则第一个请求将更新资源; 休息N-1请求将一次又一次地覆盖相同的资源状态 - 实际上不会改变任何东西。因此，PUT是幂等的。
HTTP DELETE
当您调用N个类似的DELETE请求时，第一个请求将删除资源，响应将是200 (OK)或204 (No Content)。其他N-1请求将返回404 (Not Found)。显然，响应与第一个请求不同，但服务器端的任何资源都没有状态更改，因为原始资源已被删除。因此，DELETE是幂等的。
请记住，如果某些系统可能有这样的DELETE API：
DELETE /item/last
在上述情况下，调用N次操作将删除N个资源 - 因此DELETE在这种情况下不是幂等的。在这种情况下，一个好的建议可能是将上面的API更改为POST - 因为POST不是幂等的。
POST /item/last
现在，这更接近HTTP规范 - 因此更符合REST。
