解释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，这就是我偶然发现整个概念的地方。 如果II有一个“转移资金”用例，该怎么办？ 通过一个调用，我想更改两个资源的状态，即account1和account2。 我是否将它作为代表account1的资源的PUT，并将account2作为参数？ 我是否希望我的消费者对两个帐户资源都进行PUT？ 我是否将交易内容解释为一个名词，例如“ FundTranser”，并要求我的消费者发布该消息？

对于业务域中的许多对象发生不同类型的更新的事实又如何呢？ 如果我有25个不同的用例，它们更新了ACCOUNT的不同方面，那么我真的期望通过对ACCOUNT资源的PUT完成所有这些工作吗？

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

在大多数人的心中，术语REST的意思是“非SOAP”。 他们想到的就是任何基于HTTP的原始XML。

对于所有人，我的问题是，到底有关系吗？ 如果我与他们争辩说他们的设计不是“真正的REST”，那我只是坚持一个学术观点吗？ 通过HTTP进行POX是否会丢失任何内容？ 称之为REST有什么害处吗？

Answer 1

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

您有更多的方法，而不仅仅是CRUD。 例如PATCH。 因此，REST不是CRUD。 您总是可以定义一个新资源来描述您想要的内容。

如果II有一个“转移资金”用例，该怎么办？ 通过一个调用，我想更改两个资源的状态，即account1和account2。 我是否将它作为代表account1的资源的PUT，并将account2作为参数？ 我是否希望我的消费者对两个帐户资源都进行PUT？ 我是否将交易内容解释为一个名词，例如“ FundTranser”，并要求我的消费者发布该消息？

在这种情况下，您要创建一些新东西：转账，是的，您应该使用POST /fundtransfers/或类似的东西。

如果我有25个不同的用例，它们更新了ACCOUNT的不同方面，那么我真的期望通过对ACCOUNT资源的PUT完成所有这些工作吗？

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

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

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

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

称之为REST有什么害处吗？

OFC。 它是。 您感到困惑是因为它和大多数初学者都一样。 我认为每个想要使用REST的人都必须先阅读Fielding论文。

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