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

Question

在良好的REST API设计方面,返回id新创建的资源是一个好主意吗？说我有一个API:

api/resource POST

我见过一些guru,他有这样的API来返回空的json并将URI插入带有Location标题的响应中.我想回来了

{ 'id': '1000' } 

这样调用者可以立即做一些事情,这样做会更好.再保存一次往返服务器.这种方法有什么问题？

Answer 1

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

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

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

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

文档格式(又称媒体类型)是Roy Fieldings首字母缩写词HATEOAS的核心概念之一.除了客户理解的入口点和媒体类型(因此前一段)之外,客户不需要任何其他先验知识.通过遵循HTTP协议规范并知道各个媒体类型表达的内容来描述可能的动作.

因此,返回URI而不是ID具有以下几个优点:

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