关于设计REST服务的三个问题

Question

我试图以正确的方式设计REST服务，但遇到了一些我不确定的时刻，但应该很常见：

1. 例如，我有实体car，我通过car/{id}得到它。如果我想单独请求汽车详细信息（具有许多其他属性的对象），该怎么办？应该看起来像car/details/{id}还是car/{id}/details？

2. 我想调用一些不是来自CRUD的动作，比如upload或uploadAndProcess。我无法直接命名它们，因为REST中不允许使用动词。请求应该如何？像POST car/{id}/upload/activate或POST car/{id}?upload=true,activate=true？

之类的东西

3. 我读过一些文章说，除了ids之外，它不允许在路径变量中使用任何内容，其他所有内容都应该作为请求属性发送。另一个说，将它们用于必需的属性是可以的。这是真的吗？

Answer 1

广告1）

从REST的角度来看，这没关系。 URL模式不是REST原则的一部分。

ad 2）

REST是关于资源的。您要调用的方法背后有哪些资源？可以将汽车的激活建模为资源。

或者您想操纵现有资源？在这种情况下，请使用POST /car/{id}，其中包含您要在请求正文中更改的属性。

ad 3）

两者都是假的。 REST没有说明URL的哪个部分具有什么含义。重要的是URL标识资源。如果使用路径或查询参数完成识别并不重要。

Answer 2

您应该查看Jim Webber撰写的Rest In Practice。

对＃2的简短回答：启用应用程序协议的资源不是域模型中的实体;它们是知道如何接收和处理文档的端点 - 域模型发生的变化是文档处理的副作用。

HTTP是文档的CRUD应用程序。因此，您在RESTful应用程序中想要的是CRUD一个文档，该文档描述了您希望应用于域模型的更改。该文档是您的命令消息，您将其发送到的资源是命令资源或命令集合资源

正如@Display Name所述，REST并不关心您使用哪种拼写作为标识符。您可以对所有标识符使用哈希值，这样就可以了。

您在此处引用的限制实际上来自各种URI设计指南。您应该遵循适用于您的项目的任何准则。如果你自己编写，最重要的是确保你与RFC 3986保持一致。这基本上说分层信息属于路径，非分层信息不属于。

您可能错过了旧的讨论：REST API Best practices: Where to put parameters?