这在任何地方都很少被提及，但Richardson的成熟度模型是实际判断Restful是API的最佳方法之一。更多信息请点击此处：

理查德森成熟度模型

剩下的一点是，如果我们同意对基本操作使用通用语言（http动词），那么可以配置基础结构来理解它们并适当地优化它们，例如，通过使用缓存头在所有级别实现缓存。

通过正确实现的restful GET操作，信息来自服务器的DB、服务器的memcache、CDN、代理的缓存、浏览器的缓存或浏览器的本地存储都无关紧要。可以使用最快、最容易获得的最新来源。

说Rest只是语法上的改变，从使用带有动作参数的GET请求到使用可用的http动词，这看起来没有任何好处，而且纯粹是修饰。重点是使用一种可以被链的每个部分理解和优化的语言。如果GET操作有副作用，则必须跳过所有HTTP缓存，否则结果将不一致。

这是一个令人惊讶的漫长的“讨论”，但至少可以说相当令人困惑。

IMO:

1） 没有一个大的酒吧和大量的啤酒，就没有一个安静的程序：）

2） 代表性状态转移（REST）是罗伊·菲尔丁（Roy Fielding）论文中提出的一种体系结构风格。它有许多限制。如果您的服务/客户尊重这些，那么它就是RESTful。就这样。

您可以（显著地）总结以下约束：

无状态通信遵守HTTP规范（如果使用HTTP）清晰传达传输的内容格式使用超媒体作为应用程序状态引擎

还有一个很好的帖子很好地解释了事情。

许多答案复制/粘贴了有效的信息，混淆了这些信息，增加了一些混乱。人们在这里谈论级别、RESTFulURI（没有这样的东西！）、应用HTTP方法GET、POST、PUT。。。REST不是关于这个或者不仅仅是关于这个。

例如，链接-有一个漂亮的API是很好的，但最终客户端/服务器并不真正关心你获得/发送的链接，重要的是内容。

最终，只要内容格式已知，任何RESTful客户端都应该能够使用任何RESTful服务。

REST定义了6个体系结构约束，使任何web服务都成为真正的RESTful API。

统一接口客户端-服务器无国籍的可缓存的分层系统按需编码（可选）

https://restfulapi.net/rest-architectural-constraints/

如果我没有直接回答这个问题，我很抱歉，但通过更详细的例子更容易理解这一切。由于所有的抽象和术语，字段化并不容易理解。

这里有一个很好的例子：

解释REST和超文本：垃圾邮件清理机器人Spam-E

更棒的是，这里有一个简单的例子（powerpoint更全面，但你可以在html版本中获得大部分内容）：

http://www.xfront.com/REST.ppt或http://www.xfront.com/REST.html

看完这些例子后，我明白了Ken为什么说REST是超文本驱动的。但我实际上并不确定他是对的，因为/user/123是指向资源的URI，我不清楚它是否是非RESTful的，因为客户端知道它是“带外”的

xfront文档解释了REST和SOAP之间的区别，这也非常有用。当Fielding说：“这是RPC。它尖叫RPC。”时，很明显RPC不是RESTful的，所以了解这一点的确切原因很有用。（SOAP是RPC的一种类型。）

这个答案是针对初学者的，让我们了解一下目前最常用的API架构。

了解Restful编程或Restful API。首先，您必须了解什么是API，在一个非常高级的API上，它代表应用程序编程接口，它基本上是一个软件，可以由另一个软件使用，以允许应用程序相互对话。

全球使用最广泛的API类型是web API，而每当有请求时，它都会向客户端发送数据。

事实上，API不仅用于发送数据，而且并不总是与web开发、javascript、python或任何编程语言或框架相关。

API中的应用程序实际上可以意味着许多不同的事情，只要软件的pice是相对独立的。以文件系统或HTTP模块为例，我们可以说它们是一小块软件，我们可以使用它们，我们可以通过使用它们的API与它们进行交互。例如，当我们对任何编程语言的文件系统模块使用read-file函数时，我们实际上使用的是file_system_reading API。或者，当我们在浏览器中进行DOM操作时，我们实际上并不是在使用JavaScript语言本身，而是在使用浏览器向我们公开的DOM API，因此它为我们提供了访问它的权限。或者，再举一个例子，让我们用Java等任何编程语言创建一个类，然后向其添加一些公共方法或财产，这些方法将成为从该类创建的每个对象的API，因为我们给其他软件提供了与我们的初始软件（在本例中为对象）交互的可能性。S0，API实际上具有比构建web API更广泛的含义。

现在让我们来看看构建API的REST体系结构。

REST（代表代表性状态转移）基本上是一种以逻辑方式构建web API的方式，使其易于为自己或他人使用。

要按照REST架构构建Restful API，我们只需要遵循几个原则。1.我们需要将API分成逻辑资源。2.然后应使用基于资源的URL公开这些资源。3.要对数据执行不同的操作，如读取、创建或删除数据，API应使用正确的HTTP方法，而不是URL。4.现在，我们实际发送回客户端或从客户端接收到的数据通常应该使用JSON数据格式，如果应用了某种格式标准。5.最后，EST API的另一个重要原则是它们必须是无状态的。

将API分离为逻辑资源：REST中信息的关键抽象是一种资源，因此，我们希望在API中共享的所有数据都应该划分为逻辑资源。什么是资源？好吧，在REST的上下文中，它是一个对象或某个事物的表示，它有一些与之相关的数据。例如，像导游、用户、地点或评论之类的应用程序就是逻辑资源的例子。因此，基本上任何可以命名的信息都可以是资源。不过，只需要命名，而不是动词。

暴露结构：现在我们需要暴露，这意味着使用一些结构化的URL来提供数据，客户端可以向其发送请求。例如，像这样的整个地址被称为URL。并且调用了这个/addNewTour和API端点。

我们的API将有许多不同的端点，如下所示

https://www.tourguide.com/addNewTour
https://www.tourguide.com/getTour
https://www.tourguide.com/updateTour
https://www.tourguide.com/deleteTour
https://www.tourguide.com/getRoursByUser
https://www.tourguide.com/deleteToursByUser

这些API中的每一个都会将不同的数据发送回客户端，并执行不同的操作。现在，这里的这些端点有一些非常错误的地方，因为它们确实没有遵循第三条规则，即我们应该只使用HTTP方法来对数据执行操作。因此，端点应该只包含我们的资源，而不是我们对其执行的操作，因为它们很快就会成为维护的噩梦。

我们应该如何在实践中使用这些HTTP方法？好了，让我们看看这些端点实际上应该是如何以/getTour开头的。所以这个getTour端点是为了获取关于一个旅游的数据，所以我们应该简单地命名这个端点/旅游，并在向这个端点发出get请求时发送数据。换句话说，当客户端使用GET HTTP方法访问端点时，

（我们只有端点或URL中的资源，没有动词，因为动词现在在HTTP方法中，对吗？通常的做法是总是使用复数形式的资源名称，这就是我写/tours或/tours的原因。）惯例是，当调用端点/游览时，将返回数据库中的所有游览，但如果我们只希望游览具有一个ID，比如说七个，我们会在另一个斜杠（/tours/7）或搜索查询（/tours？ID=7）中添加七个，当然，它也可以是游览的名称而不是ID。

HTTP方法：这里真正重要的是端点名称如何与所有端点名称完全相同。

GET: (for requesting data from the server.)

https://www.tourguide.com/tours/7
POST: (for sending data to the server.)
https://www.tourguide.com/tours
PUT/PATCH: (for updating requests for data to the server.) https://www.tourguide.com/tours/7
DELETE: (for deleting request for data to the server.)
https://www.tourguide.com/tours/7

PUT和PATCH之间的差异->通过使用PUT，客户端应该发送整个更新的对象，而使用PATCH，客户端应该只发送已更改的部分对象。

通过使用HTTP方法，用户可以执行基本的四个CRUD操作，CRUD代表创建、读取、更新和删除。

现在可能会出现如下情况：

因此，/getToursByUser可以简单地转换为/users/tours，对于第3号用户，终点将类似/users/3/tours。

如果我们想删除特定用户的特定游览，那么URL应该是/users/3/tours/7，这里是用户id:3和游览id:7。

因此，像这样整合资源的可能性真的很多。

以JSON形式发送数据：现在，关于客户端实际接收到的数据，或者服务器从客户端接收到的，我们通常使用JSON数据格式。典型的JSON可能如下所示：在发送JSON数据之前，我们通常会进行一些简单的响应格式化，这有几个标准，但其中一个非常简单的标准叫做Jsend。我们只需创建一个新对象，然后向其添加一条状态消息，以通知客户端请求是成功、失败还是错误。然后我们将原始数据放入一个名为data的新对象中。

像我们在这里所做的那样，将数据包装到一个额外的对象中称为包络，这是缓解一些安全问题和其他问题的常见做法。

Restful API应该始终是无状态的：最后，Restful API应该总是无状态的，这意味着，在无状态的Restful API中，所有状态都在客户端处理，而不是在服务器上。状态只是指应用程序中可能随时间变化的一段数据。例如，某个用户是登录的还是在一个包含多个页面的列表的页面上，当前页面是什么？现在，状态应该在客户端上处理这一事实意味着每个请求都必须包含在服务器上处理特定请求所需的所有信息。因此，为了处理当前请求，服务器永远不必记住以前的请求。

让我们假设目前我们在第五页，我们想前进到第六页。因此，我们可以有一个名为/tours/nextPage的简单端点，并向服务器提交一个请求，但服务器必须确定当前页面是什么，并根据该页面将下一个页面发送给客户端。换句话说，服务器必须记住先前的请求。这正是我们希望在RESTful API中避免的。

我们应该创建一个/tours/page端点，而不是这种情况并将数字6粘贴到其上，以请求第6页/游览/第6页。所以服务器不必记住其中的任何内容，它所要做的就是按照我们的要求发回第六页的数据。

无状态和无状态是计算机科学和一般应用中非常重要的概念