缓解POST响应的"最佳"练习

Question

所以这里没什么新鲜的,我只是想弄清楚一些,似乎无法在其他帖子中找到任何内容.

我正在创造一个新的资源,说:

/books (POST)

身体:

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

我知道我应该返回201(Created),其中包含新资源的Location头:

Location: /books/12345

我似乎无法回答的问题是服务器应该在体内返回什么.

我经常做这种反应:

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

我这样做有几个原因:

我为像angularjs这样的前端框架编写了api.在我的特定情况下,我使用角度资源,我经常只需要资源的ID来找到它.如果我没有在响应正文中返回id,我需要从Location头解析它.
在所有书籍的GET中,我通常返回整个对象而不仅仅是id.从这个意义上说,我的客户端代码不必区分从哪里获取id(位置标题或正文).

现在我知道我真的在这里的灰色区域,但大多数人都说回归整个资源是"坏"的做法.但是,如果服务器更改/添加信息到资源,该怎么办？它肯定会添加id,但也可能添加其他内容,如时间戳.在我不返回整个资源的情况下,最好是进行POST,返回id,然后让客户端执行GET以获取新资源.

Answer 1

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

它说:

为了防止API使用者必须再次访问API以获得更新的表示,请让API返回更新(或创建)的表示作为响应的一部分.

对我来说似乎非常实用,它符合我上面提到的REST原则.

如何返回整个相关对象？这样,可以在服务器端完成可能的排序,并且简化了前端实现 (5认同)
但这些最佳实践并不是最好的。作者指出，HATEOAS 与其他原则一样重要，但不得使用，因为“它还没有准备好”。HATEOAS永远不会“准备好”，因为所有的RESTful原则都只是架构设计原则，而不是具体实现。引用的参考文献是关于作者对 RESTful API 的看法，由于放弃了 HATEOAS，它根本不是 RESTful。这就是为什么这不是最好的参考:) (2认同)
@marcinn - 你会注意到原来的问题引用了“最佳”，我想是因为在这个领域有很多意见。我指出的参考资料是我发现很实用的。如果您有更好的参考，请分享。我总是愿意学习更多。 (2认同)

Answer 2

在更新上返回整个对象似乎不太相关,但我几乎看不出为什么在创建它时返回整个对象在正常用例中是不好的做法.这至少可以很方便地获取ID并在相关时获取时间戳.这实际上是使用Rails搭建脚手架时的默认行为.

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

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

我知道这是旧的,但我可以给你一个令人信服的论据,让你在POST后使用GET.在http/1.1规范中,任何历史工具都可以忽略从GET响应传回的缓存设置...因此,如果您的用户在使用POST更新它后使用浏览器中的后退按钮返回此页面,则可以使用陈旧来自原始GET的缓存数据.因此,如果您重复使用GET,那么您可以更新缓存并更好地了解页面离开时的外观... (24认同)
@Shaded如果API设计为也被应用程序使用,那么您提出两个请求的参数不成立.在那里,您通常通过将模型类型的对象保留在内存中来缓存数据 - 这通常通过POST请求的响应来完成.关于浏览器,只要仍然存在GET api端点,POST请求的响应就不会真正受到伤害. (6认同)