REST API：返回新创建资源ID？

Question

就良好的REST API设计而言，返回新创建的资源的id是一个好主意吗？说我有一个API：

api/resource POST

我已经看到一些有这样的API的大师返回空的json并将URI插入到Location标头作为响应。我想回来了

{ 'id': '1000' } 

这样调用者可以立即做一些事情。再保存一次往返服务器。这种方法的问题是什么？

Answer 1

根据要求，我将我的评论作为答案重新发布，并添加了一些值得回答的细节。

通过HTTP POST方法创建新资源的常用方法是返回201 Created状态代码。因此，响应应该包含资源的当前状态作为实体主体和指向可以找到资源的URI的位置标头。不这样做可能会破坏一些客户端并阻止他们与服务的正确交互。这里的客户可能是浏览器，量身定制的＆＃34; languageOfYourChoice＆＃34;应用程序甚至其他服务。

在理想的RESTful世界中，客户端只知道一个URI开始（就像服务的入口URI，f.e。http://service.company.com/）。调用该URI的响应应该返回一个客户可以理解的文档，并包含客户端可以使用的其他链接。这个概念类似于人类每天使用的大哥HTML和类似的Web资源，其中链接可以用于从起始页面移动到子页面甚至外部资源或其他超媒体资源。 REST只是Web事物的抽象和概括。

虽然不是实际问题的一部分而且这是基于意见的，但RESTful开发者之间正在讨论常见文档类型和专用文档类型（mime类型，...）的有用性。我认为应该有一个标准化的通用REST感知格式的JSON，XML，...仅仅application/json是不够的，因为这没有定义如何包含链接和模式。甚至HAL对于URI上的可执行操作以及调用这些URI时需要哪些文档格式以及需要将哪些参数传递给服务的描述不够（IMO）。

文档格式（a.k.a媒体类型）是Roy Fieldings首字母缩写HATEOAS的核心概念之一。除了客户理解的入口点和媒体类型（因此前一段）之外，客户不需要任何其他先验知识。可以通过遵循HTTP协议规范并了解相应媒体类型表达的内容来描述可能的操作。

因此，返回URI而不是ID有几个优点：

• URI本身是唯一的，但不同的供应商可能具有相同的ID
• 客户端不需要知道服务器如何创建这些URI，另一方面服务器几乎可以免费提供它们。返回产品ID 1234几乎无法通过客户端在URI中组合 - 客户端因此需要有关如何创建URI的特殊知识，以便服务器实际上能够正确处理请求。 / LI>
• 服务器可以移动资源而无需客户端进行更改，因为客户端（在理想的RESTful世界中）将在进一步的请求中检索资源的URI。响应。因此，客户只需要知道返回字段的语义知识＆＃34;意味着＆＃34;