解释 REST 中的“资源”

Question

帮助我了解 REST 以资源为导向的重要性。 Fielding 论文的第 5.2.1.1 节说“REST 中信息的关键抽象是资源”。我一直认为这意味着对 REST 服务的资源导向。我有一个资源，比如司机、车辆或帐户。我可以通过 URI 与此资源进行交互，并且我的交互性质由 HTTP 动词描述。 POST 用于创建，PUT 用于更新等。

如果有人来找我设计一个名为“updateAddress”之类的 REST 服务，我的直觉会说它不是 REST。它的名字中有一个动词。资源应该用名词命名。您可以实现一个系统，允许消费者通过 HTTP 上的普通 XML 调用 updateAddress 操作，它会正常工作。但它不是 REST。要成为 REST，资源应该是“地址”。您可以使用 POST、PUT、GET 和 DELETE 创建、更新、检索和删除它。

只要您的应用程序所需的所有交互都是 CRUD，我的 REST 概念就可以正常工作。但并非一切都是 CRUD，这就是我偶然发现整个概念的地方。如果我有一个“转移资金”用例，我该怎么做？通过一次调用，我想更改两个资源 account1 和 account2 的状态。我是否将其作为代表 account1 的资源的 PUT，并将 account2 作为参数？我是否希望我的消费者对两个帐户资源都进行 PUT？我是否将我的交易解释为一个名词，例如“FundTranser”，并要求我的消费者发布？

对于业务域中的许多对象都会发生不同类型的更新这一事实如何？如果我有 25 个不同的用例来更新 ACCOUNT 的不同方面，我真的希望通过 PUT 到 ACCOUNT 资源来完成所有这些用例吗？

我的经验是，大多数人只是忽略了这一点。他们设计了一个名称中带有动词的操作，就像他们设计 SOAP 服务操作时所做的那样。该操作名称成为其消息正文中的根元素。他们对所有事情都使用 POST。甚至“deleteAccount”和“retrieveAccount”操作都是 POST。

在大多数人的心目中，REST 一词的意思是“非 SOAP”。在他们看来，任何基于 HTTP 的普通 XML 都是 REST。

我对你们所有人的问题是，归根结底，这重要吗？如果我与他们争辩说他们的设计不是“真正的 REST”，我是否只是坚持学术观点？通过 HTTP 执行 POX 是否会丢失任何内容？将其称为 REST 有什么害处吗？

Answer 1

只要您的应用程序所需的所有交互 是 CRUD，我对 REST 的概念很好。但并非一切都是 CRUD，这就是我偶然发现整个概念的地方。

您有更多方法，而不仅仅是 CRUD。例如补丁。所以 REST 不是 CRUD。你总是可以定义一个描述你想要什么的新资源。

如果我有一个“转移资金”用例，我该怎么做？用单 调用，我想改变两个资源的状态，account1，和 帐户2。我是否将其作为代表资源的 PUT account1，并让 account2 成为参数？我是否希望我的消费者 对两个帐户资源进行 PUT？我是否解释我的交易 变成一个名词，例如“FundTranser”，并要求我的消费者发布 那个？

在这种情况下，您正在创建新的东西：传输，所以是的，您应该使用 POST /fundtransfers/ 或类似的东西。

如果我有 25 个不同的用例，我更新了 ACCOUNT，我真的希望通过 PUT 完成所有这些任务吗？ ACCOUNT 资源？

您可以使用 PATCH 进行部分更新，也可以定义子资源并在其上使用 PUT。

• PATCH /account {name: "..."}
• PATCH /account/name "..."

我的经验是，大多数人只是忽略了这一点。

是的，他们不开发 REST 服务。他们只是声称他们是，因为将所有东西都称为 REST 是一种炒作。

称它为 REST 有什么坏处吗？

办公室。它是。你因为它而感到困惑，和大多数初学者的感觉一样。我认为每个想要使用 REST 的人都必须先阅读菲尔丁的论文。

顺便说一句，REST 和 RESTful 这两个词已经被那些不在乎的人用尽了。因此，现在我们使用术语 Web API 和超媒体 API 来区分违反 REST 约束的 Web 服务和满足的稀有 Web 服务。