REST API 设计：在哪里创建依赖于其他资源的资源？

REST API Design: Where to create Resource that depends from other resource?

如果我有两个资源，其中一个是从另一个创建的，我应该将创建端点放在哪里？

示例：

我有两个资源，A 和 B，我想创建一个 B。

B 是一个简单的 class，它引用 A 和创建它的用户，就像这样

public class B {
    private A a;
    private User user;
}

用户信息是通过 HTTP 请求隐式发送的，因此我不需要任何参数。

解决方案一：

向/A/123/B和returnB发送不带任何参数的POST。这意味着A的Controller负责创建B。感觉很奇怪。

方案二：

发送一个 ID 为 123 的 POST 到 /B。这意味着如果存在 ID 为 123 的 A，我必须检查 B 的控制器。感觉也奇怪。

两种解决方案的优缺点是什么？我是不是想多了 API 设计？

你需要清楚依赖性

A是由B组成的吗？换句话说，B 是否存在于 A 范围之外？

  1. 如果答案是肯定的，B可以没有A活着，最好有一个单独的资源：

    POST ./B

您应该避免将资源放置在不同的位置路径中。有些人可能会争辩说，REST 不会强制您为一种资源使用单个端点，但保持跨不同端点的一致性并不是那么明显。如果您发送 DELETE ./A/{id}，B 会怎样？

  1. 如果回答是否定的，意味着B不存在，除非A存在，那么最好将B作为子资源。

    POST ./A/{id}/B

说到控制器，没有什么可以迫使您从其他控制器管理 B。 REST 的全部要点是调用不是指向控制器而是指向资源。您正在创建的资源独立于控制器。