在所有情况下我应该从POST返回实体吗？

Question

据我所知,RESTful 约定是为POST创建一个资源来返回完整或带注释的创建实体,但是我的经验是,除非正在测试服务本身或客户端,否则通常会丢弃此实体.

在创建面向公众的API时,我不是REST的奴隶,特别是当我认为出于可用性或架构原因它没有意义时,但我总是想知道并且从未做过的一件事是204 No Content从POST 返回创建新实体(特别是那些大尺寸的).这可以减少用户提出大量请求的带宽,并更快地做出回应.

这是一种可以接受的做法,还是会让你死在里面？请注意,出于测试原因,如果不提供端点来检索此实体,我不会考虑这一点.

编辑:我正在寻找轶事观察或具体的例子,说明为什么这个特定用例可能有害,即使它有详细记录.

Answer 1

您链接到的文档可以回答您提出的问题:

如果在源服务器上创建了资源,则响应应该是201(已创建)并包含描述请求状态的实体,并引用新资源和Location头(请参阅第14.30节).

除非响应包含适当的Cache-Control或Expires头字段,否则对此方法的响应不可缓存.但是,303(请参阅其他)响应可用于指示用户代理检索可缓存资源.

Answer 2

关于 的使用204 No Content，根据规范，当创建未由 URI 标识的资源200时，您将返回此（或 ） 。POST如果这正确描述了您的用例，那么 a204将是合适的。

正如 @Dmitry 在他的评论中提到的，返回的实体不一定是新资源。例如，如果资源的 ID 由服务器分配，则响应可能是仅包含该服务器生成的 ID 的实体。

CouchDB的 POST 文档中显示了具体的示例。

对于此示例请求：

POST /somedatabase/ HTTP/1.0
Content-Length: 245
Content-Type: application/json

{
  "Subject":"I like Plankton",
  "Author":"Rusty",
  "PostedDate":"2006-08-15T17:30:12-04:00",
  "Tags":["plankton", "baseball", "decisions"],
  "Body":"I decided today that I don't like baseball. I like plankton."
}

服务器响应将是一个包含状态、ID 和修订版本的实体：

HTTP/1.1 201 Created
Date: Thu, 17 Aug 2006 05:39:28 +0000GMT
Content-Type: application/json
Connection: close

{"ok":true, "id":"123BAC", "rev":"946B7D1C"}