这就是它可能看起来的样子。

创建具有三个财产的用户：

POST /user
fname=John&lname=Doe&age=25

服务器响应：

200 OK
Location: /user/123

以后，您可以检索用户信息：

GET /user/123

服务器响应：

200 OK
<fname>John</fname><lname>Doe</lname><age>25</age>

要修改记录（姓名和年龄将保持不变）：

PATCH /user/123
fname=Johnny

要更新记录（因此lname和age将为NULL）：

PUT /user/123
fname=Johnny

这个答案是针对初学者的，让我们了解一下目前最常用的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页。所以服务器不必记住其中的任何内容，它所要做的就是按照我们的要求发回第六页的数据。

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

为了在这里贡献一些新的东西，我想分享我文章中的链接，即通过一种实用和客观的方法将REST概念化。

我将介绍以下主要概念：

HATEOAS-超媒体作为应用程序状态的引擎，资源和表示，可寻址性，REST中的幂等性，Richardson的REST成熟度模型。媒体类型API版本控制

我还创建了一个GitHub项目，您可以使用docker轻松运行，它涵盖了我在本文中介绍的内容。

https://itnext.io/how-to-build-a-restful-api-a-deep-dive-into-rest-apis-215188f80854

一种称为REST（RepresentationalStateTransfer）的体系结构风格主张web应用程序应该像最初设想的那样使用HTTP。查找应使用GET请求。PUT、POST和DELETE请求应分别用于变异、创建和删除。

REST支持者倾向于使用URL，例如

http://myserver.com/catalog/item/1729

但REST架构不需要这些“漂亮的URL”。带有参数的GET请求

http://myserver.com/catalog?item=1729

完全是RESTful的。

请记住，GET请求不应用于更新信息。例如，向购物车添加项目的GET请求

http://myserver.com/addToCart?cart=314159&item=1729

这是不合适的。GET请求应该是幂等的。也就是说，发出两次请求与发出一次请求应该没有区别。这就是请求可缓存的原因。一个“添加到购物车”请求不是幂等的，发出两次请求会向购物车添加两个项目副本。POST请求显然适合于这种情况。因此，即使是RESTful web应用程序也需要共享POST请求。

这摘自大卫·M·Geary的优秀著作《核心JavaServer面孔》。

一本关于REST的好书是《实践中的REST》。

必须读取代表性状态传输（REST），并且REST API必须是超文本驱动的

有关RESTful服务的解释，请参见Martin Fowlers的文章《Richardson成熟度模型》（RMM）。

要实现RESTful，服务需要实现作为应用程序状态引擎的超媒体。（HATEOAS），也就是说，它需要达到RMM中的3级，阅读文章以了解详细信息或qcon演讲中的幻灯片。

HATEOAS约束是首字母缩略词超级媒体的引擎应用程序状态。这一原则是REST之间的关键区别以及大多数其他形式的客户端服务器系统...RESTful应用程序的客户端需要只知道要访问的单个固定URL所有未来的行动都应该可从中动态发现超媒体链接包含在资源的表示从该URL返回。标准化媒体类型也是预期任何人都能理解可能使用RESTful API的客户端。（来自免费百科全书维基百科）

Web框架的REST Litmus测试是Web框架的类似成熟度测试。

接近纯REST：学会爱HATEOAS是一个很好的链接集合。

针对公共云的REST与SOAP讨论了REST使用的当前级别。

REST和版本控制讨论了可扩展性、版本控制、可演化性等。通过可修改性

如果我不得不将关于REST的原始论文缩减为短短的3句话，我认为以下内容抓住了它的精髓：

通过URL请求资源。协议仅限于使用URL进行通信的内容。元数据作为名称-值对（发布数据和查询字符串参数）传递。

之后，很容易陷入关于适应、编码约定和最佳实践的争论。

有趣的是，本文中没有提到HTTPPOST、GET、DELETE或PUT操作。这一定是后来有人对“统一界面”的“最佳实践”的解释。

当涉及到web服务时，我们似乎需要一些方法来区分WSDL和基于SOAP的体系结构，这会给接口增加相当大的开销和不必要的复杂性。它们还需要额外的框架和开发人员工具才能实现。我不确定REST是否是区分常识接口和过度工程化接口（如WSDL和SOAP）的最佳术语。但我们需要一些东西。