API 中的 CreateOrUpdate 职责答案

【问题标题】：CreateOrUpdate responsibility in an APIAPI 中的 CreateOrUpdate 职责
【发布时间】：2017-08-22 14:15:18
【问题描述】：

这是一个通用的设计问题，但在这种情况下，责任应该落在哪里？检查记录是否已经存在然后调用更新是否应该是调用者的责任？还是应该由 API 负责做出该决定？

在第一种场景中，问题在于调用者背负了业务逻辑，而在第二种场景中，逻辑污染了API并产生了混合行为，违反了关注点分离原则。

【问题讨论】：

标签： api api-design solid-principles separation-of-concerns

【解决方案1】：

实现 CreateOrUpdate 端点将违反一些 REST 原则，但可能对应用程序开发人员很方便。您考虑的是远程函数调用，而不是面向资源的 API。

考虑一下：API URL 标识资源。

如果 URL 指向一个集合（即 /customers/），那么 Create 操作（通常映射到 POST 方法）当然是有意义的。如果您希望一次允许对多个资源进行更新，则更新功能可能很有意义。 POST 应该返回代码 201 和一个新创建资源的标识符（即 /customers/1）；或者如果由于资源已经存在而创建失败，它应该返回代码 409；如果不满足其他一些约束，例如数据验证，则为 400。

如果 URL 指向现有资源（即 /customers/id/1），则 Create 操作没有意义，应导致代码 400。更新通常映射到 PUT 方法（或有时 PATCH，如果部分资源更新），如果更新成功则返回 200，否则返回 4xx 系列。

如果您选择创建一个接受 POST 请求的 /CreateOrUpdate 端点，您将不得不围绕它设计自己的协议，因为它的行为和返回值会因情况而异。

@Evert PUT 可用于创建，但仅当您要求客户端使用标识符制定端点 URI 时，即

PUT /users/myusername

问题是：

客户端必须发现一个可用的，
如果使用自然标识符，也可能存在更改它的自然原因，这取决于实现可能会出现问题

我的主要观点是避免创建代表动作（函数）的 REST API 端点。而是使用 HTTP 方法来实现对持久资源的相应操作。

【讨论】：

为什么这个 REST 答案适用于“通用设计问题”？
我不同意创建或更新违反 REST。 stackoverflow.com/questions/630453/put-vs-post-in-rest 这正是 PUT 的用途。
PUT 也是创建新资源的正确http动词。人们为此使用POST 的唯一原因是因为他们不希望客户端确定资源uri，而是让服务器确定它。如果您有一个适合 URI 的自然键，则始终更喜欢 PUT 而不是 POST 进行创建。所以这个答案是完全错误的。