使用单个 URI 和单个请求处理多个 HTTP 方法的正确方法是什么

Question

我想了解解决以下问题的正确请求/响应结构和 API 设计。 我有 2 个实体，比如说 Abc 和 Xyz。 Xyz 的外键是 Abc。 因此，要为 Xyz 创建一条记录，必须有映射的 Abc 记录。

现在从请求结构的角度来看，我需要为 Abc 创建一个类似的 POST 请求

POST /Abc

这非常简单。但问题在于 Xyz。 要求是每当用户来创建 Xyz 时，他也可以请求更新附加的 Abc 记录。 例如， 我为 Abc 创建了一条 id 为 5 的记录。现在，每当我想创建相应的 Xyz 记录时，我都会请求更新 id 为 5 的 Abc 记录，并为此外键创建一条新的 Xyz 记录。 所以， 补丁/ABC 和 发布 /XYZ 但是客户端只请求一次，并在单个 URI 上共享整个数据。

那么，在单个 URI 上处理多个 HTTP 方法的正确方法是什么？ 我应该创建 POST 请求还是 PATCH？

我无法创建 2 个请求，因为客户希望这个过程是事务性的。

Answer 1

首先我猜你应该这样想

我无法创建 2 个请求，因为客户希望这个过程是事务性的。

以另一种方式。正如我所看到的，对事务性的要求可能只是意味着——我可能在这方面大错特错，所以找出真相——当Abc 也有更新时，创建新Xyz 的过程与更新@ 是事务性的987654324@。因此，如果 Abc 的更新失败（反之亦然）并返回一些错误，则不会创建 Xyz。

所以你也许可以创建两个端点：

• 一个只有 POST 的人：一个新的Xyz
• 另一个用于创建新的Xyz 并同时以事务方式更新Abc

所以您也许可以创建两个端点。这里更有趣的是后者是POST还是PATCH？似乎两者兼而有之，是的。

但是看到-例如-this question & accepted answer，还有关于PATCH：

PATCH 方法请求将请求实体中描述的一组更改应用于由 Request-URI 标识的资源

现在，下面的问题是Abc由Request-URI标识改变了吗？如果不是，那么它就是 - 据我了解 - POST。

这意味着您应该只需要一个 POST 端点来检查是否有需要并执行所需的事务更新 id。但也许有单独的端点会更好。