52

一世了解（我认为）RESTful-ness 背后的基本思想。语义上使用 HTTP 方法 - GET 获取、PUT 放置、DELETE 删除等……对吗？以为我理解 REST 背后的想法，但我认为我将其与 HTTP 实现的细节混淆了。休息背后的驱动理念是什么，为什么这变得很重要？人们是否真的在我的手电筒从未照过的互联网角落里使用了很长时间？

Google 演讲提到 Atom 发布协议与 RESTful 实现有很多协同作用。对此有什么想法吗？

4

5 回答 5

56

这就是 REST 的样子：

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

服务器响应：

201 Created
Location: /user/123

将来，您可以检索用户信息：

GET /user/123

服务器响应（假设是 XML 响应）：

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

更新：

PUT /user/123
fname=Johnny
于 2009-07-04T05:59:18.020 回答
19

这是我的看法...

制作 RESTful 服务的吸引力在于，我们不是使用数十种功能方法创建 Web 服务，而是标准化了四种方法（创建、检索、更新、销毁）：

  • 邮政
  • 得到
  • 放
  • 删除

REST 变得越来越流行，因为它还代表了应用层消息格式的标准化。虽然 HTTP 使用 REST 的四个基本动词，但 HTML 的常见 HTTP 消息格式并不是构建应用程序的合同。

我听到的最好的解释是 TCP/IP 与 RSS 的比较。

以太网代表物理网络上的标准化。Internet 协议 (IP) 代表了更高层次的标准化，并且有几种不同的风格（TCP、UDP 等）。“传输控制协议”（保证数据包传递）的引入定义了通信合同，为我们打开了应用层的全新服务集（FTP、Gopher、Telnet、HTTP）。

以此类推，我们采用 XML 作为“协议”，我们现在开始标准化消息格式。RSS正迅速成为许多 RESTful 服务的基础。Google 的 GData API 是 RSS/ATOM 变体。

“桌面小工具”很好地体现了这种炒作：一个简单的客户端可以使用通用 API 和消息传递标准来使用基本的 Web 内容或复杂的混搭。

于 2008-10-28T15:22:47.060 回答
12

HTTP 目前使用不足和误用。

我们通常只使用 HTTP 的两种方法：GET 和 POST，但还有更多：DELETE、PUT 等（http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html）

因此，如果我们拥有由 RESTful URL 定义的资源（您的应用程序中的每个域对象都有唯一的 URL，形式为http://yoursite.com/path/to/the/resource）和体面的 HTTP 实现，我们可以在您的领域通过写句子：

获取http://yoursite.com/path/to/the/resource

删除http://yoursite.com/path/to/the/resource

发布http://yoursite.com/path/to/the/resource

ETC

建筑很好，一切都很好。

但这只是理论观点，在我之前的答案中发布的所有链接中都描述了现实世界的场景。

于 2008-10-28T14:23:32.577 回答
10

让我们回到历史，谈谈 Roy Fielding 的研究——“<a href="https://www.ics.uci.edu/~fielding/pubs/dissertation/fielding_dissertation.pdf" rel="noreferrer">建筑风格和基于网络的软件架构的设计“。它是一篇大论文，谈论了很多各种各样的东西。但是作为一名标准工程师，您想如何解释清楚 REST（Representational State Transfer）的含义，以及它的架构风格是什么。

这是我的解释方式——“什么是 REST”。

请参阅在各种硬件（例如路由器、服务器、防火墙、云基础设施、交换机、LAN、WAN）上运行的 www（万维网）。这个 www（万维网）的总体目标是分发超媒体。这个万维网配备了各种服务，例如基于信息的服务、网站、youtube 频道、动态网站、静态网站。这个万维网使用 HTTP 协议通过客户端/服务器机制在世界范围内分发超媒体。此 HTTP 协议在 TCP/IP 或其他适当的网络堆栈之上工作。

此HTTP 协议使用八种方法来管理“分发协议”或“分发架构风格”。这八种方法分别是：OPTIONS、GET、HEAD、POST、PUT、DELETE、TRACE、CONNECT。

但是在这个 HTTP 之上，Web 应用程序正在使用它自己的方式来分发超媒体，例如 Web 应用程序正在使用与客户端和服务器高度相关的 Web 服务，或者 Web 应用程序正在使用它自己设计的客户端/服务器机制的方式来制作这种基于 HTTP 的分发渠道。

正如Roy Fielding Research所说，HTTP 的这八种方法 OPTIONS、GET、HEAD、POST、PUT、DELETE、TRACE、CONNECT 非常成功地在各种硬件资源和网络堆栈与客户端的基础上向世界各地提供超媒体/server 机制，我们为什么不对基于 Web 的应用程序也使用类似的策略。在此 GET、POST、DELETE 和 PUT 上使用最多。所以四种方法将超媒体传送到世界各地。

在 REST API架构风格的应用程序中，Web 应用程序需要设计业务逻辑（驻留在服务器中，例如 Tomcat、Apache HTTP）与所有对象实体集（例如客户是一个实体）和可能的操作（例如“基于检索客户信息”在客户 id') 上。这些实体的那些可能的操作应该设计有四个主要的操作或方法，即创建、检索、更新、删除。这些实体称为资源，它们以 JSON 或 XML 或其他形式呈现或表示。我们有客户端（浏览器）调用创建、检索、更新、删除（CRUD）方法来对驻留在服务器中的此类资源执行适当的功能。

但正如Representation的概念所解释的那样，表示业务逻辑或对象的实体的方式。但是“状态转移”呢？

状态转移，它谈论从客户端到服务器的“通信状态” 。它讨论了从客户端到服务器的“状态转移”的设计，例如客户端首先调用操作“创建客户”，然后调用此操作将是客户的下一个状态或“客户”可以调用的客户状态。它的状态可能是“检索创建的客户端数据”、“更新客户端数据”或什么

于 2015-09-11T02:46:57.047 回答
5

REST 是一种定义和处理资源的架构。

为了更好地理解 REST，您应该查看面向资源的架构 (ROA)，它为实际实施 REST 架构提供了一组指导方针。

REST 不需要通过 HTTP，但它是最常见的。REST 最初是由 HTTP 的创建者之一创建的。

于 2008-10-28T13:59:55.993 回答