RESTful编程到底是什么？

RESTful编程到底是什么？

一种称为REST（代表性状态转移）的体系结构样式主张Web应用程序应使用最初设想的 HTTP 。查找应使用请求。，和请求应分别用于突变，创建和删除。GETPUTPOSTDELETE

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请求共享。

这摘自David M. Geary 的出色著作《Core JavaServer Faces》。

REST是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-可能支持许多媒体类型）。客户端和服务器都已被编程为可以理解这种格式，但是它们彼此之间一无所知。正如Roy Fielding指出的那样：

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"
        }
    ]
}

从这个回应中我们可以看出很多。例如，我们现在知道我们可以通过创建一个新用户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的方式更加一致。首先是写这个，而不是真正的意思。我已经修改了答案，以更好地代表真实的意思。）

RESTful编程是关于：

• 资源由持久标识符标识：URI是当今标识符的普遍选择
• 资源使用一组共同的动词被操纵：HTTP方法是常见的情况-古老Create，Retrieve，Update，Delete变POST，GET，PUT，和DELETE。但是REST不限于HTTP，它只是目前最常用的传输方式。
• 检索到的资源的实际表示形式取决于请求，而不取决于标识符：使用Accept标头控制您是否要使用XML，HTTP甚至是表示该资源的Java对象
• 保持对象中的状态并在表示中表示状态
• 在资源表示中表示资源之间的关系：对象之间的链接直接嵌入在表示中
• 资源表示形式描述了如何使用表示形式以及在何种情况下应以一致的方式丢弃/重新获取该表示形式：HTTP Cache-Control标头的使用

就REST的后果和整体有效性而言，最后一个可能是最重要的。总体而言，大多数RESTful讨论似乎都集中在HTTP及其在浏览器中的用法，而没有。我了解R. Fielding在描述导致HTTP的体系结构和决策时创造了该术语。他的论文更多地是关于资源的体系结构和缓存能力，而不是HTTP。

如果你是在一个RESTful架构是真正感兴趣的，为什么它的作品，读了他的论文了几次，看了整个事情不只是第5章！接下来研究DNS为什么起作用。阅读有关DNS的层次结构以及引用如何工作的信息。然后阅读并考虑DNS缓存如何工作。最后，阅读HTTP规范（特别是RFC2616和RFC3040），并考虑缓存如何以及为什么以这种方式工作。最终，它只会单击。对我来说，最后的启示是当我看到DNS和HTTP之间的相似之处时。在此之后，开始理解为什么SOA和消息传递接口是可伸缩的。

我认为理解RESTful和无共享架构的体系结构重要性和性能含义的最重要技巧是避免陷入技术和实现细节上。专注于谁拥有资源，谁负责创建/维护资源等，然后考虑表示形式，协议和技术。

这就是它的样子。

创建具有三个属性的用户：

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>

修改记录（lname并且age将保持不变）：

PATCH /user/123
fname=Johnny

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

PUT /user/123
fname=Johnny

关于REST的一本很棒的书是REST in Practice。

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

有关什么是RESTful服务的说明，请参阅Martin Fowlers的Richardson成熟度模型（RMM）。

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

HATEOAS约束是Hypermedia作为应用程序状态引擎的首字母缩写。该原理是REST与大多数其他形式的客户端服务器系统之间的主要区别。

...

RESTful应用程序的客户端只需要知道一个固定的URL即可访问它。应该从该URL返回的资源表示形式中包含的超媒体链接中动态发现所有未来的动作。可能会使用RESTful API的任何客户端也希望理解标准媒体类型。（维基百科，自由的百科全书）

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

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

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

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

什么是REST？

REST代表代表性状态转移。（它有时被拼写为“ ReST”。）它依赖于无状态，客户端-服务器，可缓存的通信协议-几乎在所有情况下，都使用HTTP协议。

REST是用于设计网络应用程序的体系结构样式。这个想法是，与其使用诸如CORBA，RPC或SOAP之类的复杂机制在计算机之间进行连接，不如使用简单的HTTP在计算机之间进行调用。

在许多方面，基于HTTP的万维网本身都可以视为基于REST的体系结构。RESTful应用程序使用HTTP请求来发布数据（创建和/或更新），读取数据（例如进行查询）和删除数据。因此，REST将HTTP用于所有四个CRUD（创建/读取/更新/删除）操作。

REST是RPC（远程过程调用）和Web服务（SOAP，WSDL等）之类的机制的轻量级替代。稍后，我们将了解REST更简单。

尽管简单，但REST具有完整的功能。基本上，在Web服务中您无法做的事是RESTful架构无法完成的。REST不是“标准”。例如，永远不会有针对REST的W3C建议。尽管存在REST编程框架，但是使用REST是如此简单，以至于您经常可以使用Perl，Java或C＃等语言的标准库功能来“自己动手”。

当我尝试找到休息的简单真实含义时，我找到了最好的参考之一。

http://rest.elkstein.org/

REST使用各种HTTP方法（主要是GET / PUT / DELETE）来处理数据。

您无需使用特定的URL来删除方法（例如/user/123/delete），而是向该/user/[id]URL 发送DELETE请求，编辑用户，检索有关将GET请求发送给用户的信息。/user/[id]

例如，取而代之的是一组可能类似于以下内容的URL。

GET /delete_user.x?id=123
GET /user/delete
GET /new_user.x
GET /user/new
GET /user?id=1
GET /user/id/1

您使用HTTP“动词”并具有..

GET /user/2
DELETE /user/2
PUT /user

在程序设计中，您的系统架构适合Roy Fielding在其论文中提出的REST风格。由于这是描述Web的建筑风格（或多或少），因此许多人对此感兴趣。

额外的答案：不会。除非您以软件专家的身份学习软件架构或设计Web服务，否则确实没有理由听到这个词。

我要说的是RESTful编程是关于创建遵循REST体系结构样式的系统（API）。

我发现M. Elkstein博士撰写的这个关于REST的奇妙，简短且易于理解的教程，并引用了将在很大程度上回答您的问题的基本部分：

学习REST：教程

REST是用于设计网络应用程序的体系结构样式。这个想法是，与其使用诸如CORBA，RPC或SOAP之类的复杂机制在计算机之间进行连接，不如使用简单的HTTP在计算机之间进行调用。

• 在许多方面，基于HTTP的万维网本身都可以视为基于REST的体系结构。

RESTful应用程序使用HTTP请求来发布数据（创建和/或更新），读取数据（例如进行查询）和删除数据。因此，REST将HTTP用于所有四个CRUD（创建/读取/更新/删除）操作。

我不认为您不应该因为没有在Stack Overflow之外听到REST而感到愚蠢……我会处于同样的情况！关于REST为什么现在变得如此庞大的另一个SO问题的答案可能会缓解一些感觉。

抱歉，如果我没有直接回答问题，请通过更详细的示例更轻松地理解所有内容。由于所有的抽象和术语，对字段的理解并不容易。

这里有一个很好的例子：

解释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。）

什么是REST？

用REST的官方术语来说，REST是一种使用当前“ Web”基础知识以某些原则为基础的建筑风格。Web具有5个基本基础，可用于创建REST服务。

• 原则1：一切都是资源在REST体系结构样式中，数据和功能被视为资源，并且可以使用统一资源标识符（URI）（通常是Web上的链接）进行访问。
• 原则2：每个资源都由唯一标识符（URI）标识
• 原则3：使用简单统一的接口
• 原则4：沟通是通过代表来完成的
• 原则5：无国籍

我看到一堆答案，说将有关用户123的所有内容都放在资源“ / user / 123”上是RESTful的。

创造了该术语的Roy Fielding说，REST API必须是超文本驱动的。特别是，“ REST API不得定义固定的资源名称或层次结构”。

因此，如果您的“ / user / 123”路径在客户端上进行了硬编码，则它不是真正的RESTful。很好地使用HTTP，也许，也许不是。但不是RESTful。它必须来自超文本。

答案很简单，有一篇由Roy Fielding撰写的论文。] 1在那篇论文中，他定义了REST原理。如果一个应用程序满足所有这些原则，那么这就是一个REST应用程序。

之所以创建RESTful是因为ppl通过将非REST应用程序称为REST来用尽REST这个词。之后，RESTful一词也被用尽。如今，我们正在谈论Web API和Hypermedia API，因为大多数所谓的REST应用程序并未满足统一接口约束的HATEOAS部分。

REST约束如下：

1. 客户服务器架构

   因此，它不适用于PUB / SUB套接字，它基于REQ / REP。

2. 无状态沟通

   因此，服务器不维护客户端的状态。这意味着您不能使用服务器端会话存储，而必须对每个请求进行身份验证。您的客户端可能通过加密连接发送基本身份验证标头。（通过大型应用程序，很难维护许多会话。）

3. 如果可以的话，使用缓存

   因此，您不必一次又一次地处理相同的请求。

4. 统一接口作为客户端和服务器之间的通用合同

   服务器不维护客户端与服务器之间的合同。换句话说，必须将客户端与服务的实现分离。您可以通过使用IRI（URI）标准来标识资源，HTTP标准来交换消息，用于描述主体序列化格式的标准MIME类型，元数据（可能是RDF vocab，微格式等）等标准解决方案来达到此状态。描述消息主体不同部分的语义。要使IRI结构与客户端脱钩，您必须以超媒体格式（例如HTML，JSON-LD，HAL等）向客户端发送超链接。因此，客户端可以使用分配给超链接的元数据（可能是链接关系，RDF vocabs）来通过适当的状态转换来导航应用程序的状态机，以实现其当前目标。

   例如，当客户想要向网上商店发送订单时，则必须检查网上商店发送的响应中的超链接。通过检查链接，它找到了一个用http://schema.org/OrderAction描述的链接。客户端知道schema.org vocab，因此它了解通过激活此超链接将发送订单。因此，它将激活超链接并POST https://example.com/api/v1/order以适当的正文发送消息。此后，服务将处理该消息，并201 - created以成功的方式响应具有正确的HTTP状态标头的结果。要用详细的元数据注释消息，标准解决方案使用RDF格式，例如带有REST vocab的JSON-LD，例如Hydra 和特定于域的schema.org或任何其他链接的数据词汇表，如果需要的话，也许还可以定制特定于应用程序的词汇表。现在这并不容易，这就是为什么大多数ppl使用HAL和其他简单格式的原因，这些格式通常仅提供REST vocab，但不提供链接数据支持。

5. 建立分层系统以增加可伸缩性

   REST系统由层次结构层组成。每一层都包含使用下一层中组件服务的组件。因此，您可以轻松添加新的图层和组件。

   例如，有一个包含客户机的客户机层，在其下有一个包含单个服务的服务层。现在，您可以在它们之间添加客户端缓存。之后，您可以添加另一个服务实例和负载均衡器，依此类推...客户端代码和服务代码将保持不变。

6. 按需编码以扩展客户端功能

   此约束是可选的。例如，您可以将特定媒体类型的解析器发送给客户端，依此类推...为了执行此操作，您可能需要在客户端中使用标准的插件加载器系统，否则您的客户端将与插件加载器解决方案耦合。

REST约束导致高度可伸缩的系统，其中客户端与服务的实现分离。因此，客户端可以像网络上的浏览器一样可重用。客户端和服务共享相同的标准和词汇，因此尽管客户端不知道服务的实现细节，但是他们可以彼此理解。这样就可以创建可以查找和利用REST服务实现其目标的自动化客户端。从长远来看，这些客户可以像人类一样相互交流并在任务上彼此信任。如果我们向此类客户添加学习模式，那么结果将是使用机器网络而不是单个服务器园区的一个或多个AI。因此，最后是Berners Lee的梦想：语义网和人工智能将成为现实。因此，到2030年，我们最终被天网终止。直到那时 ... ;-）

RESTful（表示状态传输）API编程遵循以下5种基本软件体系结构样式原则，以任何编程语言编写Web应用程序：

1. 资源（数据，信息）。
2. 唯一的全局标识符（所有资源均由URI唯一标识）。
3. 统一接口 -使用简单和标准接口（HTTP）。
4. 表示法-所有通信均通过表示法完成（例如XML / JSON）
5. 无状态的（每个请求都是完全隔离的，因此更易于缓存和负载均衡），

换句话说，您正在通过HTTP编写简单的点对点网络应用程序，该应用程序通过实现RESTful架构来建议每个“资源”公开的接口标准化，从而使用诸如GET，POST，PUT或DELETE之类的动词。以简单有效的方式（高度成功，经过验证的分布式架构）使用Web的当前功能并不是什么。它是诸如SOAP，CORBA和RPC之类的更复杂机制的替代方法。

RESTful编程符合Web体系结构设计，并且如果正确实现，则可以使您充分利用可伸缩Web基础结构。

如果我不得不将关于REST的原始论文减少为3个简短的句子，那么我认为以下内容可以抓住其实质：

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

之后，很容易陷入有关改编，编码约定和最佳实践的辩论。

有趣的是，本文中没有提到HTTP POST，GET，DELETE或PUT操作。那一定是某人以后对“统一接口”的“最佳实践”的解释。

当涉及到Web服务时，似乎我们需要某种区分WSDL和SOAP体系结构的方法，这会增加相当大的开销并为接口带来不必要的复杂性。他们还需要其他框架和开发人员工具才能实施。我不确定REST是否是区分常识接口和过度设计的接口（例如WSDL和SOAP）的最佳术语。但是我们需要一些东西。

REST是编写分布式应用程序的体系结构模式和风格。从狭义上讲，它不是一种编程风格。

说您使用REST风格类似于说您以特定风格建造房屋：例如Tudor或Victorian。可以通过构成它们的质量和约束来定义REST作为软件样式还是Tudor或Victorian作为家庭样式。例如，REST必须具有客户端服务器分隔，其中消息是自描述的。都铎风格的房屋有重叠的山墙和与前山墙陡峭倾斜的屋顶。您可以阅读Roy的学位论文，以了解有关构成REST的约束和质量的更多信息。

与家庭风格不同的是，REST一直很难被一致和实际地应用。这可能是故意的。将其实际实现留给设计者。因此，只要满足创建论文中列出的约束，您就可以自由地做自己想做的事情。

奖金：

整个网络都基于REST（或REST基于网络）。因此，尽管没有必要编写优质的Web应用程序，但作为Web开发人员，您可能想知道这一点。

这是我对REST的基本概述。我试图证明RESTful架构中每个组件背后的想法，以便使理解概念更为直观。希望这有助于使REST神秘化！

REST（代表性状态转移）是一种设计体系结构，概述了网络资源（即共享信息的节点）的设计和寻址方式。通常，RESTful体系结构使其可以使客户端（请求计算机）和服务器（响应计算机）可以请求读取，写入和更新数据，而客户端不必知道服务器的运行方式和服务器可以通过它不需要知道客户端的任何信息。好的，很酷...但是我们如何在实践中做到这一点？

• 最明显的要求是，需要某种通用语言，以便服务器可以告诉客户端它正在尝试处理请求并让服务器响应。

• 但是要找到任何给定的资源然后告诉客户该资源在哪里，就需要一种通用的指向资源的方式。这就是通用资源标识符（URI）的来源。它们基本上是查找资源的唯一地址。

但是REST架构还不止于此！尽管以上内容满足了我们所需的基本需求，但我们也希望拥有一种支持高流量的体系结构，因为任何给定的服务器通常都处理来自多个客户端的响应。因此，我们不想让服务器记住有关先前请求的信息而使服务器不堪重负。

• 因此，我们施加了以下限制：客户端和服务器之间的每个请求-响应对都是独立的，这意味着服务器不必记住有关先前请求（客户端-服务器交互的先前状态）的任何内容即可响应新请求。请求。这意味着我们希望我们的交互是无状态的。

• 为了进一步减轻服务器上的负担，使其无法重做最近针对给定客户端执行的计算，REST还允许进行缓存。基本上，缓存是指对提供给客户端的初始响应进行快照。如果客户端再次发出相同的请求，则服务器可以为客户端提供快照，而不是重做创建初始响应所需的所有计算。但是，由于它是快照，因此如果快照尚未过期（服务器预先设置了过期时间），并且响应自初始缓存以来已更新（即，请求将给出与缓存响应不同的答案） ，客户端将看不到更新，直到缓存过期（或清除缓存）并且再次从头开始呈现响应。

• 关于RESTful架构，您经常会碰到的最后一件事是它们是分层的。在讨论客户端和服务器之间的交互时，我们实际上已经在隐式讨论此要求。基本上，这意味着我们系统中的每一层仅与相邻层交互。因此，在我们的讨论中，客户端层与服务器层交互（反之亦然），但是可能还有其他服务器层可以帮助主服务器处理客户端不直接与之通信的请求。而是服务器根据需要传递请求。

现在，如果所有这些听起来都很熟悉，那就太好了。通过互联网定义通信协议的超文本传输​​协议（HTTP）是RESTful体系结构抽象概念的实现（如果您是像我这样的OOP狂热者，则可以是REST类的实例）。在REST的此实现中，客户端和服务器通过GET，POST，PUT，DELETE等进行交互，它们是通用语言的一部分，可以使用URL指向资源。

我认为，重点在于将有状态性分离为更高的层，同时利用互联网（协议）作为无状态传输层。大多数其他方法将事情混在一起。

这是处理互联网时代编程的根本变化的最佳实践方法。关于基本更改，Erik Meijer在此处进行了一场讨论：http : //www.infoq.com/interviews/erik-meijer-programming-language-design-effects-purity#view_93197。他将其概括为五个效果，并通过将解决方案设计为编程语言来提出解决方案。无论使用哪种语言，都可以在平台或系统级别上实现该解决方案。宁静可以看作是在当前实践中非常成功的解决方案之一。

风格宁静，您可以在不可靠的Internet上获取和操纵应用程序的状态。如果它无法使当前操作获得正确的当前状态，则需要零验证主体来帮助应用程序继续。如果无法操纵状态，则通常使用多个阶段的确认来保持状态正确。从这个意义上讲，REST本身并不是一个完整的解决方案，它需要Web应用程序堆栈其他部分的功能来支持其工作。

鉴于此观点，其余样式并不真正与Internet或Web应用程序绑定。这是许多编程情况的基本解决方案。这也不是简单的，它只是使界面真正简单，并且可以很好地应对其他技术。

只是我的2c。

编辑：两个重要方面：

• 无国籍是一种误导。它与宁静的API有关，与应用程序或系统无关。系统必须是有状态的。宁静的设计是关于基于无状态API设计有状态系统。来自其他质量检查的一些报价：

  • REST对资源表示进行操作，每个资源表示由一个URL标识。这些通常不是数据对象，而是复杂的对象抽象。
  • REST代表“代表性状态转移”，这意味着它全部与通信和修改系统中某些资源的状态有关。

• 幂等性：REST中经常被忽略的部分是大多数动词的幂等性。这导致了健壮的系统，并减少了语义精确解释的相互依赖性。

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

海事组织：

1）没有足够的程序，没有很大的接口和大量的啤酒:)

2）代表性状态转移（REST）是Roy Fielding论文中指定的一种建筑风格。它有很多限制。如果您的服务/客户端尊重这些，那么它就是RESTful的。就是这个。

您可以总结（显着）约束到：

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

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

许多答案会复制/粘贴有效信息，将其混合在一起并增加混乱。人们在这里谈论级别，关于RESTFul URI（没有这样的东西！），应用HTTP方法GET，POST，PUT……REST与之无关或不仅如此。

例如链接-拥有一个外观精美的API很好，但是最后，客户端/服务器并不真正在乎您获取/发送的链接，而是内容很重要。

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

老问题，新的回答方式。关于这个概念有很多误解。我总是试图记住：

1. 结构化URL和Http方法/动词不是静态编程的定义。
2. JSON不是宁静的编程
3. RESTful编程不适用于API

我将宁静的编程定义为

如果应用程序以客户端可以理解的媒体类型提供资源（即数据和状态转换控件的组合），则它是宁静的

要成为一名宁静的程序员，您必须尝试构建允许参与者执行操作的应用程序。不只是公开数据库。

仅当客户端和服务器同意资源的媒体类型表示形式时，状态转换控件才有意义。否则，就无法知道什么是控件，什么不是控件以及如何执行控件。IE，如果浏览器不知道<form>html中的标记，那么您就没有任何内容可以提交到浏览器的过渡状态。

我不想自我提升，但是我会在我的演讲http://techblog.bodybuilding.com/2016/01/video-what-is-restful-200.html中深入探讨这些想法。

我演讲的摘录是关于经常提到的理查森成熟度模型，我不相信这些级别，您要么是RESTful（级别3），要么您不是，但是我想指出的是每个级别在您走向RESTful的过程中为您做的

REST定义了6种架构约束，这些约束使任何Web服务都成为真正的RESTful API。

1. 统一的界面
2. 客户端服务器
3. 无状态
4. 可缓存的
5. 分层系统
6. 按需代码（可选）

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

REST === HTTP类比是不正确的，除非您不强调它“必须”由HATEOAS驱动。

罗伊本人在这里清除了它。

输入REST API时，除了最初的URI（书签）和适合目标受众（即，可能会使用该API的任何客户端都希望理解）的一组标准化媒体类型外，没有其他先验知识。从那时起，所有应用程序状态转换都必须由客户端选择服务器提供的选择来驱动，这些选择出现在接收到的表示形式中或由用户对这些表示形式的暗示来暗示。过渡可以由客户端对媒体类型和资源通信机制的了解来确定（或受其限制），这两者都可以动态地（例如，按需编码）进行改进。

[此处的失败表示带外信息正在驱动交互，而不是超文本。

REST是一种基于Web标准和HTTP协议（于2000年引入）的体系结构样式。

在基于REST的体系结构中，一切都是资源（用户，订单，注释）。通过基于HTTP标准方法（GET，PUT，PATCH，DELETE等）的公共接口访问资源。

在基于REST的体系结构中，您拥有一个REST服务器，该服务器提供对资源的访问。REST客户端可以访问和修改REST资源。

每个资源都应支持HTTP通用操作。资源由全局ID（通常是URI）标识。

REST允许资源具有不同的表示形式，例如文本，XML，JSON等。REST客户端可以通过HTTP协议（内容协商）请求特定的表示形式。

HTTP方法：

PUT，GET，POST和DELETE方法通常在基于REST的体系结构中使用。下表说明了这些操作。

• GET定义了对资源的读取访问，而没有副作用。资源永远不会通过GET请求进行更改，例如，该请求没有副作用（幂等）。
• PUT创建一个新资源。它也必须是幂等的。
• DELETE删除资源。这些操作是幂等的。它们可以重复出现而不会导致不同的结果。
• POST更新现有资源或创建新资源。

REST代表代表性状态转移。

它依赖于无状态，客户端-服务器，可缓存的通信协议-几乎在所有情况下，都使用HTTP协议。

REST通常用于移动应用程序，社交网站，混搭工具和自动化业务流程中。REST风格强调通过有限数量的操作（动词）来增强客户端和服务之间的交互。通过为资源（名词）分配自己的唯一通用资源指示符（URI），可以提供灵活性。

休息介绍

说话不仅仅是交流。交换信息。实际上，设计了一个协议，因此不必进行通话。各方都知道自己的特定工作是什么，因为它是在协议中指定的。协议允许进行纯信息交换，但要以可能的动作进行任何更改为代价。另一方面，交谈允许一方询问另一方可以采取哪些进一步的措施。他们甚至可以问同样的问题两次，并得到两个不同的答案，因为在此期间对方的国家可能已经改变。谈论的是RESTful体系结构。Fielding的论文指定的架构，一个人必须要遵循，如果有人想，让机器说话彼此，而不是简单地

本身没有“ RESTful编程”这样的概念。最好将其称为RESTful范例，甚至更好的RESTful体系结构。它不是编程语言。这是一个范例。

来自维基百科：

在计算中，代表性状态转移（REST）是用于Web开发的一种体系结构样式。

休息点是，如果我们同意对基本操作（http动词）使用通用语言，则可以将基础结构配置为理解它们并适当地优化它们，例如，通过使用缓存头来实现缓存。水平。

通过正确实现的静态GET操作，信息是否来自服务器的数据库，服务器的内存缓存，CDN，代理的缓存，浏览器的缓存或浏览器的本地存储都无关紧要。可以使用禁食的，最容易获得的最新来源。

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

什么是API测试？

API测试利用编程将调用发送到API并获得收益。它会将测试中的段视为黑匣子。API测试的目的是在协调到应用程序之前，确认零件的正确执行和过失处理。

REST API

REST：代表性状态转移。

• 测试人员在此功能上执行请求并接收响应。在REST API中，交互是通过HTTP协议进行的。
• REST还允许计算机之间通过网络相互通信。
• 对于发送和接收消息，它涉及使用HTTP方法，并且与Web服务不同，它不需要严格的消息定义。
• REST消息通常接受XML或JavaScript Object Notation（JSON）形式的形式。

4种常用的API方法：

1. GET：–它提供对资源的只读访问。
2. POST：–用于创建或更新新资源。
3. PUT：–用于更新或替换现有资源或创建新资源。
4. 删除：–用于删除资源。

手动测试API的步骤：-

要手动使用API​​，我们可以使用基于浏览器的REST API插件。

1. 安装POSTMAN（Chrome）/ REST（Firefox）插件
2. 输入API URL
3. 选择REST方法
4. 选择内容标题
5. 输入请求JSON（POST）
6. 点击发送
7. 它将返回输出响应

自动化REST API的步骤

这在每个地方都很少被提及，但是理查森的成熟度模型是实际判断一个人的API有多宁静的最佳方法之一。有关此的更多信息：

理查森的成熟度模型

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

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