假设我们提供了添加新酒店的服务：
> POST /hotel
> <hotel>
> <a>aaa</a>
> <b>aaa</b>
> <c>aaa.......this is 300K</c>
> </hotel>
然后我们得到了一个：
> GET /hotel
< HTTP/1.1 200 OK
< <hotel>
< <a>aaa</a>
< <b>aaa</b>
> <c>aaa.......this is 300K</c>
< </hotel>
问题是我们为初始POST创建返回什么？我们想要返回ID（在服务器上生成）以获得新资源的“参考”，但我们不想返回所有酒店数据，因为在我们的例子中，其中一个数据字段是〜300K的平面文件
所以你应该回来：
< HTTP/1.1 200 OK
< <hotel>
< <id>123</id>
< </hotel>
或者你应该返回完整的对象：
< HTTP/1.1 200 OK
< <hotel>
< <id>123</id>
< <a>aaa</a>
< <b>aaa</b>
> <c>aaa.......this is 300K</c>
< </hotel>
...
我对宁静的最佳实践感兴趣。
注意：这个相关的post更多地讨论了返回什么，但更少关于如何返回它。
答案 0 :(得分：40)
返回状态代码201 - 已创建，并将URL放在Location标头中。你根本不需要返回一个尸体。
答案 1 :(得分：14)
REST就是关于资源的URL。
最好的RESTful做法是返回用于访问刚刚创建的资源的URL。
我不会退回整个文件。除非由于某种原因它对协议很重要（比如服务器可能会更改客户端提交的数据并且客户端想要确认它没问题）。如果不重要，客户已经知道数据。
如果您只返回ID，客户端将不知道如何处理它。但是返回URL将允许客户端继续与服务器的REST交互（可能是通过获取服务描述文档）。这并不是说您不能将ID与URL一起返回。但是URL，因为它是一个Web系统，是您可以知道的最重要的信息。此外，ID很可能是您内部需要的内容，而不是客户应该担心的问题。
编辑：
至于是否应该将返回的URL包装在XML中，它实际上取决于您的协议。如果您认为将来可能想要返回其他数据，那么XML将更加谨慎。使用指定的文件格式可以让您更好地对服务进行版本控制（通过更改文档类型标题）。但你可以只返回URL。
答案 2 :(得分：10)
在响应中返回Location头和实际实体主体的一个好处是客户端可以在一次到服务器的往返中接收结果表示。例如，AtomPub就是这样做的。