对于REST，在创建资源时是否使用身体或查询参数？

Question

我正在开发一个数字媒体库，用户可以在其中为媒体资源创建条目。

媒体资源由数以吨计的财产组成，如：

Media:{
  id, 
  name,
  type,
  private,
}

用户用于创建资源的url是

POST api/media

在后端，我们使用为它们生成的UID创建资源，同时默认名称、类型和私有值。但是，用户可以传递名称、类型和私有信息，如果他们选择的话。

RFC 4.3.3似乎对这些数据是否使用params或post body没有意见。

所以这样做更好吗？

api/media?type="audio"&name="Hopkins County Collective"&private=false

还是用身体代替？

api/media

body{
   name:
   type:
   private:
}

在阅读了4.3.3节的帖子后，https://www.rfc-editor.org/rfc/rfc7231#section-4.3.3和我看到了这篇文章

Providing a block of data, such as the fields entered into an HTML
      form, to a data-handling process;

我倾向于身体中的柱子，但我仍然不确定。

谢谢

Answer 1

在创建资源时是否使用身体或查询参数？

身体。但事情可能比这更复杂。

HTTP给了我们标准化的消息语义--通过采用通用标准，我们都同意给定消息的含义。当我们得到信息时，这并不一定会限制我们对信息的处理。

例如。

PUT /id=1 HTTP/?.?
Content-Type: text/plain

id=2

该消息意味着我们希望/id=1标识的资源具有表示id=2。换句话说，这是客户端的未来行为。

GET /id=1 HTTP/?.?

200 OK
Content-Location: /id=1
Content-Type: text/plain

id=2

因此，主体描述了我们希望表示的内容，而有效的uri标识了我们正在讨论的文档。

同样的基本模式适用于POST和修补程序--有效的--uri告诉我们我们想要改变哪种资源，身体描述这种变化。

但是..。

实际上，您并不要求服务器执行请求要求您做的事情。您可以拒绝请求(4xx)，也可以执行类似于请求的操作，并将此告知客户端。

因此，作为隐藏在REST外观后面的实现的一部分，您可以在有效-uri之外复制信息，或者准确地应用客户端在请求主体中提供的指令。(您必须对响应元数据稍微小心一点，以确保您所做的工作不会有任何含糊之处)。

Answer 2

有趣的是，“几乎每个人”似乎都在使用身体来表示他们希望创建的资源看起来、存在或包含什么。

参数通常根本不可能被使用，如果它们仅用于控制如何创建该资源的各个方面，而不是与资源的外观、存在或包含有任何关系。

我说的是轶事，因为我确信这是有例外的--你甚至在考虑它。也就是说，REST并没有具体说明参数和身体之间的关系。

为了从容不迫，为了“像其他人一样去做”，就和身体一起去吧。

还有其他一些与参数无关的注意事项: 1)它们是URI的一部分，URI用于标识目的；2)查询字符串长度受到高度限制，因此无法创建大型对象；3)这将是一个诊断/调试噩梦，在您的头脑中解析查询字符串，试图理解它。