你能解释一下 RESTful 的 Web 概念吗？答案

【问题标题】：Can you explain the Web concept of RESTful?你能解释一下 RESTful 的 Web 概念吗？
【发布时间】：2009-02-16 00:42:33
【问题描述】：

寻找对这个概念的清晰简洁的解释。

【问题讨论】：

标签： web-services rest

【解决方案1】：

我找到的最好的解释是在这个REST tutorial。

【讨论】：

非常感谢。我得出的结论是，大多数谈论 REST 和 RESTful 的人并不真正理解他们在说什么。一个令人满意的解释绝对必须，除其他外，1）给出例子； 2) 说明 REST 与解决相同问题的其他解决方案有何不同； 3）解释为什么选择“代表性状态转移”这个表述而不是其他表述。您的链接页面（rest.elkstein.org - 10 年后仍然存在）在前几段中做了所有这些事情。
在 99% [估计] 的情况下，归结为：“让服务器通过在域后至少一个斜杠或问号之后使用带有短或长文本的 URL 来执行操作名称，结合 GET 或 POST”。在莫里哀的Le Bourgeois Gentilhomme中，同名角色惊讶地发现他一直在“说散文”......！

【解决方案2】：

RESTful 应用程序是一种将其状态和功能公开为一组资源的应用程序，客户端可以对其进行操作并遵守一组特定原则：

所有资源都是唯一可寻址的，通常通过 URI；不过，也可以使用其他寻址方式。
所有资源都可以通过一组受限制的众所周知的操作进行操作，通常是 CRUD（创建、读取、更新、删除），最常通过 HTTP 的 POST、GET、PUT 和 DELETE 表示；它可以是不同的集合或子集 - 例如，某些实现将集合限制为仅读取和修改（GET 和 PUT）
所有资源的数据都通过任何有限数量的众所周知的表示形式传输，通常是 HTML、XML 或 JSON；
客户端和应用程序之间的通信是通过无状态协议执行的，该协议允许多层中介机构可以为客户端和应用程序透明地重新路由和缓存请求和响应数据包。

Tim Scott 所指的Wikipedia article 给出了更多关于 REST 的起源、详细原理、示例等细节。

【讨论】：

不幸的是，在尝试理解 REST 时，推断 CRUD 映射到 GET、PUT、POST、DELETE 极具误导性。下一个问题总是，“但是如果我必须做其他操作怎么办”。正如您在稍后的评论中提到的，PUT 可以创建，正如我所解释的，POST 可能无法创建。忘记 CRUD！
XML 和 Json 是在 REST 中使用的可怕的媒体类型。它们真正起作用的唯一场景是在浏览器中执行 AJAX 时，您正在下载理解 XML/JSON 格式的 Java 脚本。在其他情况下，您需要使用语义上更有意义的数据类型。
@Darell - XML 和 JSON 都是最广泛使用的两种资源表示格式，因此无论它们是否是最好的，都应该提及它们。这同样适用于 CRUP 及其 HTTP 动词映射。
@Darell - 我碰巧同意你对 JSON 的看法。我不确定为什么您认为 XML 是资源数据的可怕表示（而不是媒体），以及对于机器消费来说，什么是语义上更有意义的数据类型。
@AfterWorkGuinness 是的，你可以。尽管您仍然必须遵循这些原则，但这些原则使 HTTP 成为 REST 实现非常合适的协议。

【解决方案3】：

只有几点：

RESTFul 不依赖于您使用的框架。这取决于它所描述的建筑风格。如果你不遵守约束，你就不是 RESTful。约束在 Roy Fielding 的文档第 5 章的半页中定义，我鼓励您去阅读它。
标识符是不透明的，并且不携带任何超出资源标识的信息。这是一个 nmae，不是输入数据，只是名称。就客户端而言，除了知道如何从表单标签构建查询字符串之外，它没有任何逻辑或价值。如果您的客户端使用您预先确定的架构构建自己的 URI，那么您就不会安宁。
使用或不使用所有 http 动词并不是真正的约束，设计一个只支持 POST 的架构是完全可以接受的。
缓存、高度解耦、缺乏会话状态和分层架构是很少有人谈论但对于 RESTful 架构成功最重要的要点。

如果您没有花费大部分时间来设计文档格式，那么您可能没有使用 REST。

【讨论】：

【解决方案4】：

以 REST 为例：

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>

更新：

PUT /user/123
fname=Johnny

【讨论】：

【解决方案5】：

坦率地说，答案取决于上下文。 REST 和 RESTful 的含义取决于您使用的语言或框架或您要完成的任务。由于您已在“Web 服务”下标记了您的问题，我将在 RESTful Web 服务的上下文中回答，这仍然是一个广泛的类别。

RESTful Web 服务可以指任何东西，从严格的 REST 解释（所有操作都以严格的“RESTful”方式完成）到纯 XML 协议（这意味着它不是 SOAP 或 XMLRPC）。在后一种情况下，这是用词不当：这样的 REST 协议实际上是 "plain old XML" (or "POX") protocol。虽然 REST 协议通常使用 XML，因此也是 POX 协议，但这不一定是这种情况，反之亦然（仅仅因为协议使用 XML 并不能使其成为 RESTful）。

不用多说，真正的 RESTful API 由对对象执行的操作组成，由使用的 HTTP 方法和该对象的 URL 表示。这些操作是关于数据的，而不是关于方法的作用。例如，CRUD 操作（创建、读取、更新和删除）可以映射到一组特定的 URL 和操作。假设您正在与照片 API 进行交互。

要创建照片，您需要通过 POST 请求将数据发送到 /photos。它会通过 Location 标题让您知道照片在哪里，例如/photos/12345
要查看照片，您可以使用 GET /photos/12345
要更新照片，您需要通过 PUT 请求将数据发送到 /photos/12345。
要删除照片，您可以使用 DELETE /photos/12345
要获取照片列表，您可以使用 GET /photos。

可能会实施其他操作，例如通过 COPY 请求复制照片的能力。

通过这种方式，您使用的 HTTP 方法会直接映射到您的调用意图，而不是将您希望执行的操作作为 API 的一部分发送。相比之下，非 RESTful API 可能会使用更多 URL，并且仅使用 GET 和 POST 操作。因此，在此示例中，您可能会看到：

要创建照片，请将 POST 发送到 /photos/create
要查看照片，请将 GET 发送到 /photos/view/12345
要更新照片，请将 POST 发送到 /photos/update/12345
要删除照片，请将 GET 发送到 /photos/delete/12345
要获取照片列表，请将 GET 发送到 /photos/list

您会注意到在这种情况下 URL 是如何不同的，并且仅出于技术需要选择方法：要发送数据，您必须使用 POST，而所有其他请求都使用 GET。

【讨论】：

其实POST是用来表示Create和PUT to Update的。但是，由于某些服务器实现本身不支持 PUT，因此 POST 对于这两种操作都是重载的。
这是一个有争议的问题，真的。 PUT 通常用于创建。 :)
抱歉，没有争议。 :-) RFC 2616 准确地指定了 POST 和 PUT 的操作。第 2.5 段，POST 方法请求所附实体被接受为所请求 URL 的新下级。第 2.6 节，PUT 方法请求将包含的实体存储在指定的 URL 中。
该行为有一些微妙的细节，例如 PUT 可用于创建新资源。但是，POST 不应将新实体放在请求 URL 上，而 PUT 应始终将任何新实体放在请求 URL 处。这种与请求 URL 的关系将 POST 定义为 CREATE，将 PUT 定义为 UPDATE。
更多细节，这里是 RFC 2616 超文本传输协议 (HTTP1.1) 的链接 - tools.ietf.org/html/rfc2616

【解决方案6】：

这意味着使用名称来识别命令和参数。

名称不仅仅是句柄或绰号，名称本身包含信息。具体来说，有关请求内容、请求参数等的信息。

名称不是“根”，而是动作加上输入数据。

【讨论】：

有史以来最好的解释

【解决方案7】：

我从 InfoQ.com 上发表的文章中学到了最多的东西： http://www.infoq.com/rest 和 RESTful Web 服务一书 (http://oreilly.com/catalog/9780596529260/)。

./亚历克斯

免责声明：我与 InfoQ.com 有联系，但此建议是基于我自己的学习经验。

【讨论】：