宁静的POST响应的“最佳实践”

因此，这里没有什么新内容，我只是想澄清一下，似乎在其他帖子中找不到任何内容。

我正在重新创建新资源，说：

/books (POST)

与身体：

{
  title: 'The Lion, the Witch and the Wardrobe',
  author: 'C. S. Lewis'
}

我知道我应该返回带有新资源的Location标头的201（创建的）：

Location: /books/12345

我似乎无法为自己回答的问题是服务器应该返回什么内容。

我经常这样做：

{
  id: 12345,
  title: 'The Lion, the Witch and the Wardrobe',
  author: 'C. S. Lewis'
}

我这样做有两个原因：

1. 我已经为诸如angularjs的前端框架编写了api。在我的特定情况下，我使用的是角度资源，并且我通常只需要ID即可找到资源。如果我没有在响应正文中返回ID，则需要从Location标头中解析出该ID。
2. 在所有书籍的GET中，我通常返回整个对象而不仅仅是id。从这个意义上说，我的客户代码不必区分从何处获取ID（位置标头或主体）。

现在我知道我真的在这里处于灰色地带，但是大多数人都说退还全部资源是“不好的”做法。但是如果服务器将信息更改/添加到资源中该怎么办。它肯定会添加ID，但也可能添加其他内容，例如时间戳。如果我不返回整个资源，那么执行POST，返回ID，然后让客户端执行GET获取新资源真的更好吗？

在更新中返回整个对象似乎不太相关，但是我几乎看不到为什么在创建普通对象时返回一个创建对象是一个不好的做法。至少对于轻松获得ID并在相关时获得时间戳很有用。实际上，这是使用Rails脚手架时的默认行为。

我真的没有看到仅返回ID并在之后执行GET请求以获取初始POST可能获得的数据的任何优势。

无论如何，只要您的API保持一致，我认为您应该选择最适合自己需求的模式。没有任何正确的方法来构建REST API，imo。

返回新对象符合REST原则“统一接口-通过表示操作资源”。完整对象是所创建对象的新状态的表示。

关于API设计，这里有一个非常出色的参考：设计实用RESTful API的最佳实践

它在此处包含您问题的答案：更新和创建应返回资源表示形式

它说：

为了防止API使用者必须再次点击API以获得更新的表示形式，请让API返回更新（或创建的）表示形式作为响应的一部分。

对我来说似乎很实用，它符合我上面提到的REST原则。