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

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

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

REST是web的基础架构原则。web的惊人之处在于，客户端（浏览器）和服务器可以以复杂的方式交互，而客户端事先不知道服务器及其托管的资源。关键的限制是服务器和客户端都必须对所使用的媒体达成一致，在web的情况下，媒体是HTML。

遵循REST原则的API不要求客户端了解API的结构。相反，服务器需要提供客户端与服务交互所需的任何信息。HTML表单就是这样的一个例子：服务器指定资源的位置和所需的字段。浏览器事先不知道在哪里提交信息，也不知道要提交什么信息。这两种形式的信息完全由服务器提供。（这一原则被称为HATEOAS：作为应用程序状态引擎的超媒体。）

那么，这如何适用于HTTP，如何在实践中实现呢？HTTP以动词和资源为导向。主流用法中的两个动词是GET和POST，我想每个人都会认识到。然而，HTTP标准定义了其他几个，如PUT和DELETE。然后根据服务器提供的指令将这些动词应用于资源。

例如，假设我们有一个由web服务管理的用户数据库。我们的服务使用一个基于JSON的自定义超媒体，为此我们分配了mimetype application/JSON+userdb（也可能有application/xml+userdb和application/whatever+userdb-可能支持许多媒体类型）。客户机和服务器都经过编程，可以理解这种格式，但他们对彼此一无所知。正如罗伊·菲尔丁指出的：

REST API应该在定义用于表示资源和驱动的媒体类型应用程序状态，或定义扩展关系名称和/或现有标准媒体类型的超文本标记。

对基本资源/的请求可能会返回如下内容：

要求

GET /
Accept: application/json+userdb

回答

200 OK
Content-Type: application/json+userdb

{
    "version": "1.0",
    "links": [
        {
            "href": "/user",
            "rel": "list",
            "method": "GET"
        },
        {
            "href": "/user",
            "rel": "create",
            "method": "POST"
        }
    ]
}

我们从媒体的描述中知道，我们可以从“链接”部分找到有关相关资源的信息。这称为超媒体控件。在这种情况下，我们可以从这样一个部分看出，通过对/user发出另一个请求，我们可以找到一个用户列表：

要求

GET /user
Accept: application/json+userdb

回答

200 OK
Content-Type: application/json+userdb

{
    "users": [
        {
            "id": 1,
            "name": "Emil",
            "country: "Sweden",
            "links": [
                {
                    "href": "/user/1",
                    "rel": "self",
                    "method": "GET"
                },
                {
                    "href": "/user/1",
                    "rel": "edit",
                    "method": "PUT"
                },
                {
                    "href": "/user/1",
                    "rel": "delete",
                    "method": "DELETE"
                }
            ]
        },
        {
            "id": 2,
            "name": "Adam",
            "country: "Scotland",
            "links": [
                {
                    "href": "/user/2",
                    "rel": "self",
                    "method": "GET"
                },
                {
                    "href": "/user/2",
                    "rel": "edit",
                    "method": "PUT"
                },
                {
                    "href": "/user/2",
                    "rel": "delete",
                    "method": "DELETE"
                }
            ]
        }
    ],
    "links": [
        {
            "href": "/user",
            "rel": "create",
            "method": "POST"
        }
    ]
}

从这一反应中我们可以看出很多。例如，我们现在知道可以通过向/user发帖来创建新用户：

要求

POST /user
Accept: application/json+userdb
Content-Type: application/json+userdb

{
    "name": "Karl",
    "country": "Austria"
}

回答

201 Created
Content-Type: application/json+userdb

{
    "user": {
        "id": 3,
        "name": "Karl",
        "country": "Austria",
        "links": [
            {
                "href": "/user/3",
                "rel": "self",
                "method": "GET"
            },
            {
                "href": "/user/3",
                "rel": "edit",
                "method": "PUT"
            },
            {
                "href": "/user/3",
                "rel": "delete",
                "method": "DELETE"
            }
        ]
    },
    "links": {
       "href": "/user",
       "rel": "list",
       "method": "GET"
    }
}

我们还知道，我们可以更改现有数据：

要求

PUT /user/1
Accept: application/json+userdb
Content-Type: application/json+userdb

{
    "name": "Emil",
    "country": "Bhutan"
}

回答

200 OK
Content-Type: application/json+userdb

{
    "user": {
        "id": 1,
        "name": "Emil",
        "country": "Bhutan",
        "links": [
            {
                "href": "/user/1",
                "rel": "self",
                "method": "GET"
            },
            {
                "href": "/user/1",
                "rel": "edit",
                "method": "PUT"
            },
            {
                "href": "/user/1",
                "rel": "delete",
                "method": "DELETE"
            }
        ]
    },
    "links": {
       "href": "/user",
       "rel": "list",
       "method": "GET"
    }
}

请注意，我们使用不同的HTTP动词（GET、PUT、POST、DELETE等）来操纵这些资源，并且我们假设客户端的唯一知识是我们的媒体定义。

进一步阅读：

这一页上有很多更好的答案。我如何向妻子解释REST。我如何向妻子解释REST。马丁·福勒的思想PayPal的API具有超媒体控制

（这个答案因为没有抓住重点而受到了相当多的批评。在大多数情况下，这是一个公平的批评。我最初描述的内容更符合几年前我第一次写这篇文章时REST通常是如何实现的，而不是它的真正含义。我修改了答案，以更好地代表真正的含义。）

答案很简单，罗伊·菲尔丁写了一篇论文。]1在那篇论文中，他定义了REST原则。如果应用程序满足所有这些原则，那么这就是REST应用程序。

之所以创建RESTful一词，是因为ppl通过将其非REST应用程序称为REST而耗尽了REST一词。此后，RESTful一术语也耗尽了。现在我们讨论的是Web API和超媒体API，因为大多数所谓的REST应用程序都没有实现统一接口约束的HATEOAS部分。

REST约束如下：

客户端-服务器体系结构因此，它不适用于例如PUB/SUB套接字，而是基于REQ/REP。无状态通信因此，服务器不维护客户端的状态。这意味着您不能使用服务器侧会话存储，并且必须对每个请求进行身份验证。您的客户端可能通过加密连接发送基本身份验证标头。（对于大型应用程序，很难维护许多会话。）如果可以，请使用缓存因此，您不必一次又一次地满足相同的请求。作为客户机和服务器之间通用契约的统一接口客户端和服务器之间的契约不由服务器维护。换句话说，客户端必须与服务的实现分离。您可以通过使用标准解决方案来达到这种状态，例如用于标识资源的IRI（URI）标准、用于交换消息的HTTP标准、用于描述消息体序列化格式的标准MIME类型、用于描述邮件体不同部分语义的元数据（可能是RDF vocabs、微格式等）。为了将IRI结构与客户端分离，必须以超媒体格式（HTML、JSON-LD、HAL等）向客户端发送超链接。因此，客户端可以使用分配给超链接的元数据（可能是链接关系、RDF vocabs），通过适当的状态转换来导航应用程序的状态机，以实现其当前目标。例如，当客户想要向网络商店发送订单时，必须检查网络商店发送的响应中的超链接。通过检查链接，可以找到http://schema.org/OrderAction.客户机知道schema.org vocab，因此它知道通过激活这个超链接，它将发送订单。因此它激活超链接并发送POSThttps://example.com/api/v1/order以恰当的方式传递信息。之后，服务处理消息并以具有正确HTTP状态标头的结果进行响应，例如201-由成功创建。为了用详细的元数据注释消息，标准解决方案使用RDF格式，例如JSON-LD和REST vocab，例如Hydra和领域特定vocab（如schema.org或任何其他链接数据vocab），如果需要，还可以使用定制的应用程序特定vocab。现在这并不容易，这就是为什么大多数应用程序使用HAL和其他简单格式，这些格式通常只提供REST vocab，但不提供链接数据支持。构建分层系统以提高可扩展性REST系统由层次结构层组成。每一层包含使用下一层组件的服务的组件。因此，您可以轻松添加新的图层和组件。例如，有一个包含客户端的客户端层，在该层之下有一个服务层，该服务层包含单个服务。现在，您可以在它们之间添加客户端缓存。之后，您可以添加另一个服务实例和负载平衡器等…客户端代码和服务代码不会更改。扩展客户端功能的按需代码此约束是可选的。例如，您可以向客户端发送特定媒体类型的解析器，等等…为了做到这一点，您可能需要客户端中的标准插件加载器系统，或者您的客户端将耦合到插件加载器解决方案。

REST约束导致了一个高度可扩展的系统，其中客户端与服务的实现分离。因此，客户端可以是可重用的，就像web上的浏览器一样。客户机和服务共享相同的标准和语音，因此尽管客户机不知道服务的实现细节，但它们可以相互理解。这使得创建能够找到并利用REST服务实现其目标的自动化客户端成为可能。从长远来看，这些客户端可以像人类一样相互通信，在任务上相互信任。如果我们向这些客户端添加学习模式，那么结果将是一个或多个使用机器网络的人工智能，而不是一个服务器园区。因此，伯纳斯-李的梦想终于实现了：语义网络和人工智能将成为现实。因此，到2030年，我们最终被天网终止。在此之前…；-）

本质上没有“RESTful编程”这样的概念。它最好被称为RESTful范式，甚至更好的RESTful架构。它不是一种编程语言。这是一个范例。

来自维基百科：

在计算中，表示状态转移（REST）是一种用于web开发的体系结构风格。

我想说，理解REST的一个重要组成部分在于端点或映射，例如/customers/{id}/balance。

您可以将这样的端点想象为从网站（前端）到数据库/服务器（后端）的连接管道。使用它们，前端可以执行在应用程序中任何REST映射的相应方法中定义的后端操作。

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

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