api - 休息 API : reasonable to create associated resources given a verbose representation?

Question

假设我们有几个集合资源。

我可以在这个集合上创建一个实例资源:

POST /people
{
    "_links" : {
        "car" : {
            "href" : "/cars/66H8800"
        }
    }
    "name": "John"
}

但是，接受以下内容是否合理？

POST /people
{
    "_links" : {
        "car" : {
            "license" : "66H8800"
        }
    }
    "name": "John"
}

...这将导致创建资源 /people/1(例如)和 /cars/66G8800，如果 /cars/66G8800 还不存在吗？

看来我开始混合使用 POST(创建新资源)和 PUT(更新/创建特定资源)的目的。

Answer 1

执行摘要:两者都可以。我会选择 #1，但需要注意的是，您至少要在两个(可能是三个)请求中执行此操作。一个是 PUT 汽车，另一个是 POST 车主/司机。如果您事先没有汽车的完整资源数据，请在 PUT 之前为其执行 GET，并根据需要更新 PUT 请求正文。如果 GET 返回 404，则只需将 PUT 中的未知字段留空，并定义您的服务器将使用默认值填充它们(而不是拒绝 PUT 请求)。

长答案:

REST 不规定消息正文的格式。
REST 对您造成的唯一限制是:

1. 统一接口(interface)，在本例中为 HTTP 的 POST 方法。使用 POST 意味着您打算将请求主体定义的新资源附加到目标 URI 标识的集合。如果这样做要求服务器还必须在别处创建资源，那就这样吧。
2. 有记录的，最好是通用的媒体类型。使用现有的媒体类型(例如 application/hal+json )或记录您创建的媒体类型。
3. 使用超媒体(即链接)提升应用程序状态(浏览器窗口)。在请求正文中，您可以发送任何您喜欢的内容。服务器负责在其响应中提供汽车和人之间的超链接。
4. 请求必须是独立的。这意味着您不能发送一个请求“将当前汽车设置为 66H8800”，然后发送第二个请求“为当前设置的汽车创建一个驱动程序”。这样做需要在请求之间记住服务器状态，这在 REST 中是被禁止的(因为它破坏了很多东西，比如负载平衡)。看来您没有这样做，但我无法从提供的代码中看出这一点。

您的媒体类型决定了“许可证” key 是否应该存在。选择或创建一个您认为合适的。