用于保存操作的REST API设计也有可选的副作用[关闭]

Question

• 模板实体
• 子文档实体

模板可以有多个子文档如果模板被更新，则可以更新基于该实体的所有或部分子文档。

GET /templates/{id} -> Returns template
POST /templates/ -> Creates template
PUT /templates/ -> Updates template

现在，如果我们想要更新模板，并指示服务器更新所有基于模板的文档，什么是一个好的设计呢？

PUT /templates/ 
{
  template: {
    ..
  },
  childDocumentsIds: [1, 3, 7...]
}

PUT /templates?childDocumentIds=1,3,7
{
template
}

null

我正在尝试判断其他人在设计REST API时是否也有类似的问题。最近，在使用了很少的API之后，我认为我们可以做得比REST API更好。

Answer 1

我认为我们可以做得比REST API更好。

REST体系结构约束的设计考虑了一个特殊的问题：“跨多个组织的基于网络的长期应用程序”。REST的参考应用是万维网。如果这不是你的问题，那么Rest可能就不合适了。

HTTP是一种应用程序，其应用域是通过网络传输文档。如果您可以将问题框定为通过网络传输文档，那么已经为您完成了一大堆工作，如果您愿意遵守它的约束，您可以利用它。

GET /todoList

200 OK

[]

["Send an email to [e-mail]"]

然后我们会要求服务器将它的文档副本看起来像我们的副本

PUT /todoList

["Send an email to [e-mail]"]

HTTP语义告诉服务器如何解释该消息，但它可以自己选择如何处理该消息。例如，服务器可以更新它自己的/TODOLIST本地副本，将电子邮件发送给Bob，更新它的/RecentlySentEmail表示形式，更新它的/RecentlySentEmailsToBob表示形式，等等。

服务器的响应采用多种标准形式；202已接受--我理解您的要求，以后可能再做；204--没有内容--我编辑了我的文档副本以匹配您的，这里有一些元数据；200 OK--我对文档的表示形式进行了更改，它们在这里（或者，我对文档的副本进行了更改，您可以要求我提供一个刷新的副本）。

最直接的例子是发送修改后的模板，并允许服务器根据需要更新其他资源

GET /template

200 ....
[original representation of template]

// make edits

PUT /template
[revised representation of template]

200 OK

如果服务器知道哪些文档需要更新，那么它可以只更新它们。哒哒。

如果客户端需要知道哪些资源已经更新，只需将该列表发回

PUT /template
[revised representation of template]

200 OK

[URI of resources changed by the template]