javascript - 如果端点既删除资源又创建资源，它仍然是惯用的 POST 吗？

Question

我一直在尽力编写 RESTful API 端点，最近遇到了一个我不确定如何处理的场景。我创建了一个模型，该模型具有有效期的时间限制和一个端点，该端点应该:

1. 如果资源不存在则为用户创建资源
2. 删除旧资源并创建一个新资源(如果它确实存在且已过期)

我当前的实现是一个在资源创建期间处理此逻辑的端点，但在 POST 请求期间同时执行删除和创建的操作感觉不对。发出多个请求来处理同一任务也感觉不对，因为如果用户最终拥有两个资源或过于冗长的通信(如果创建请求失败、删除请求和请求失败)，这似乎会引入错误的可能性再次创造。什么是处理此问题的惯用且可靠的方法？

Answer 1

首先回答标题问题，POST 行为的删除部分不是惯用的，因为 POST 通常不用于替换，但我不认为这是严格禁止的，所以根据您的情况(如下所述)， POST 或 PUT 都是可接受的方法。

您的案例何时应使用 PUT:

如果您知道 ID，那么最好的做法是:

PUT /your/resource/path/<id>

原因:POST 意味着 更多 严格新 资源创建。在我看来，PUT 在您想要“创建或替换”的情况下使用得更多，这非常符合您的要求。

这是一个很好的资源，可以讨论和支持我所说的:

PUT vs. POST in REST

还有一个很好的摘录:

The PUT method requests that the enclosed entity be stored under the supplied Request-URI. If the Request-URI refers to an already existing resource, the enclosed entity SHOULD be considered as a modified version of the one residing on the origin server. If the Request-URI does not point to an existing resource, and that URI is capable of being defined as a new resource by the requesting user agent, the origin server can create the resource with that URI."

您的案例何时应使用 POST:

如果您的 ID 是在后端生成的和/或您不知道如何在创建时识别资源，那么出于所有相关目的，您正在创建一个新资源考虑到你对 REST 的使用，所以你应该使用 POST。您最终可能会遇到一些古怪的后端行为，有些人会争辩说这违反了 REST，但在这种情况下，除了从核心重新考虑您的解决方案之外，没有更好的选择。

最后说明:

如果您在创建时不知道 ID，那么您甚至无法退回到 DELETE →(重新)POST，因为要删除，您应该按 ID 定位。如果您在没有 ID 的情况下删除，那么您还有其他“这是惯用的”问题需要回答。