【问题标题】：What to do when REST POST provides an ID?REST POST 提供 ID 时该怎么办？
【发布时间】：2015-10-31 14:36:51
【问题描述】：

我正在开发一个 JAX-RS API，其中包含一个简单的“Person”表，其中包含“id”和“name”字段，其中“id”与 mysql 数据库中的自动编号相关联。一个典型的用例是发布一个新人。

JSON 消息 {"name":"Bob"} 的 POST 可能会返回，例如，{"id":101,"name":"Bob"}。

如果调用者请求包含标识符的对象的 POST 怎么办？看来我的选择是：

拒绝无效请求
从请求中删除id并继续处理
将 POST 视为 UPSERT（更新失败时，删除 ID 并插入）
尝试使用提供的 ID 创建新记录

从安全角度来看，最后一个选项似乎很狡猾。如果我使用 mysql，恶意用户可能会在一次请求中将我的自动编号提升到最大值。

应该如何在 REST API 中处理 POST 请求中包含的 id？

【问题讨论】：

选项 #1 或选项 #2。选项 #2 可能更方便，但如果有人稍后发布带有 id 的内容，然后不明白您为什么不使用它，则可能会造成混淆。
我赞成拒绝。如果用户发送无效请求，您永远无法确定其实际意图或错误的确切性质。
拒绝它。 400 错误请求。服务器创建的标识符的全部意义在于......好吧，创建它的服务器。这是 POST 的一般性质。允许客户干预此过程可能会产生不良后果。由于比尔提到的原因，我也远离 2，并且 PM 暗示。发送带有错误消息的 400
是的，拒绝 ID 似乎是要走的路。我还有只读的创建和更新日期字段，如果提供，我更倾向于忽略而不是拒绝。

标签： rest jax-rs autonumber

【解决方案1】：

您绝对应该拒绝所有到达/users/ 端点的请求。首先出于安全原因（在数据库级别），其次这不是客户生成/建议 ID 的工作。

因此，答案是拒绝请求无效以及相应的状态代码 (400) 和解释拒绝原因的消息。

第二个选项是不直观的，即发送和 ID（正如我所写的那样，这是一个坏主意） - 不会期望收到它发布的不同 ID。在正文中发送 ID 对 PUT 请求有意义，并且它假定对象已经创建/存在 - 这是一个更新。

第三个选项不是 RESTful - REST 中没有 upsert - POST 创建新资源。第四个选项根本没有意义 - 提供 ID 不是客户的工作。

【讨论】：

我相信根据tools.ietf.org/html/rfc7231#section-4.3.4UPSERT 语句可以很好地映射到PUT 方法
带有 ID 的 PUT 是 PUT 动词的自然应用，其预期结果是替换资源或创建资源。没有业务建议ID的客户是一种观点，充其量是一个不稳定的观点。 PK 由数据库生成，应受限于数据库实现，并且从不被客户端使用。一个好的域将在应用程序代码中分配唯一的 ID，作为该域的业务 ID。也就是说，如果您有一个瘦服务层并且域仅将您的 REST API 用作 DAL，那么在 put 中传递 ID 是正常的并且并不少见。
我也承认许多系统使用 PK 作为 ID，我只是说这是您在设计业务系统时可以做的最糟糕的事情之一，因为您现在泄露了您的数据库实现进入野外。

【解决方案2】：

另一种选择是使用 @JSonIgnore 注释忽略它。在 GET、PUT 或 DELETE 上，您将拥有 /user/{id}，因此客户端应该已经知道 ID。在 POST 上，客户端不应该发送 ID，您应该返回 ID，或者更确切地说，返回一个 URL，您可以获取创建的对象，其中包含 ID。

【讨论】：

这相当于第二个选项。

【解决方案3】：

真正归结为您希望您的 API 支持什么。

允许创建但也允许替换

向PUT /users/101 发送请求意味着您允许客户端替换或使用提供的有效负载创建 ID 为 101 的资源。对此的正常响应是，根据来自数据库的响应，如果导致替换，则返回 200，如果导致插入，则返回 201。 请注意，这是 replace 类型的更新，而不是部分更新。如果您只需要更新资源的一部分，那么您正在寻找在 RDBMS 中难以实现的 PATCH。

如果你不想要这种行为，那么就不要使用动词

如果您不想支持这种行为，那么最好的办法就是根本不允许该路由使用 PUT 动词。这是 RESTful 要做的事情。如果你已经实现了 HATEOS（实际上是 RESTful 的东西），那么 PUT 动词就不会出现在响应负载中的超媒体链接中，如果你仍然尝试使用它，它将返回 HTTP 405 Method Not Allowed。

你真的是 RESTful 的吗？

如前所述，您可以不允许 ID 并要求它在正文中，但这不是必需的，实际上也不是非常 RESTful。我的意思是——通过HATEOAS 的镜头来看待它。很容易争辩说，如果客户端需要知道 ID 应该在 PUT 的正文中（甚至可能是 ID 的名称，例如，如果您将其称为“UserID”），那么这基本上会忽略超媒体的整个目标，客户端不需要知道任何关于 API 的信息来导航它。也就是说，基本上没有人实现 HATEOAS/超媒体，但是当试图为什么是 RESTful 和什么不是 RESTful 进行争论时，这就是 IMO 的指路明灯。在真正的 RESTful API 中，客户端只需要知道资源路径和被操作实体的形状。

客户端提供的资源 ID 的问题在于，人们试图提出他们不可能知道整数标识中的下一个数字的论点。对此我要说- 嗯.. 那是你的问题。看在上帝的份上，请停止使用 PK 作为您的公共 ID。实体 ID 应该是全局唯一的，因此让客户端生成一个 GUID 以使用，例如，或者在您的服务器端为 POST 执行此操作。将其用作您的“应用程序实体 ID”。那应该是您在应用程序之间传递的 ID。你可以整天争论性能，但是 a) 对 MongoDB 这样的数据库几乎没有明显的影响，在 RDBMS 中几乎没有任何明显的影响 b) 你没有将表与应用程序 ID 链接在一起——这是一个 where 子句。您仍然在数据库端使用数据库 ID/PK，只是不要将其泄漏到野外。不过不管怎样……

当你想创建一个新资源并且不允许客户端设置 ID 时

因此，如果您的意图是允许客户端创建资源，请使用 POST。为此，不应在路由中提供 ID（例如 POST /users/101），因为这没有多大意义。如果您需要允许他们设置 ID，则按上述方式实现 PUT。如果成功，POST 的正确响应是 201 Created，并包含 Location 标头，以供客户端执行 GET 以检索其新资源。实际上，有一种称为“PRG”（Post-Redirect-Get）的模式，您可以在其中返回一个303 See Other，这将为您解决问题。这在 Web/前端上下文中效果最好，但如果客户端将自动跟随重定向，它也可以与 Client-API 一起使用。或者，您可以简单地返回 201，并在正文中包含新资源并在其中填充新 ID。

【讨论】：