3

假设我们有几个收藏资源。

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

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（更新/创建特定资源）的目的。

4

1 回答 1

1

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

长答案：

REST 并没有规定您的消息正文的格式应该是什么。
REST 对您产生的唯一限制是：

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

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

于 2013-05-29T11:25:07.293 回答