我们假设我们有一个名为shelf（书籍资源）的集合资源，我们想发布一本新书：
[POST] /shelves/{shelf-id}/books [request body -- a book]
我知道响应应该是空的，引用新创建的资源（201）或包含创建的资源（200）。
让我们说创建图书资源的客户需要显示添加新图书的书架摘要。一个解决方案应该是让客户首先进行POST（让我们称之为Req＃1 - 创建新书），然后在货架资源上进行GET（Req＃2）以获取摘要。
如果我们非常关注效率并且想要在服务器上获取Req＃1并在客户端保存一个请求时隐式返回Req＃2的结果怎么办？基于REST原则可以在将资源添加到集合时在响应中返回父集合资源信息吗？
任何替代设计？
答案 0 :(得分：1)
REST设计返回不同的资源状态是“OK”，但HTTP没有标准的方法来执行此操作。如果您为REST api使用HAL格式，它确实有一种方法可以嵌入，所以我想你可以在POST请求的响应中嵌入不同的资源。
请注意，我所知道的标准并不存在以下陈述：I know that the response should be either empty with a reference to the newly created resource (201) or include the created resource (200).
无论如何，你想要解决什么？做额外的HTTP请求真的那么贵吗？你把这个问题放在哪里？这有什么代价的？是否需要额外往返的延迟？
如果是这种情况，您可以考虑使用HTTP / 2推送来推送新版本的父资源。它可能是最符合标准的方式。如果您的服务器和客户端支持这一点，那么这也意味着您可以将其作为一种很好的标准机制，将内容推送给客户端，因为它们可能很快就会请求它。
答案 1 :(得分：0)
我知道响应应该是空的，引用新创建的资源（201）或包含创建的资源（200）。
这不是真的。 According to the spec：
新创建的资源可以由响应实体中返回的URI引用，其中包含Location头字段给出的资源的最特定URI。响应应该包括一个实体，其中包含资源特征和位置的列表，用户或用户代理可以从中选择最合适的资源特征和位置。实体格式由Content-Type头字段中给出的媒体类型指定。原始服务器必须在返回201状态代码之前创建资源。
总之，请使用201状态响应以及有关新资源的信息。请不要将有关其他资源的信息与其混合。这不是RESTful，除了迂腐之外，它可能会产生一个混乱的API，但收效甚微。