资源已存在时 POST 的 HTTP 响应代码答案

【问题标题】：HTTP response code for POST when resource already exists资源已存在时 POST 的 HTTP 响应代码
【发布时间】：2011-04-19 01:35:57
【问题描述】：

我正在构建一个允许客户端存储对象的服务器。这些对象完全在客户端构建，并带有在对象的整个生命周期内永久存在的对象 ID。

我已经定义了 API，以便客户端可以使用 PUT 创建或修改对象：

PUT /objects/{id} HTTP/1.1
...

{json representation of the object}

{id} 是对象 ID，因此它是 Request-URI 的一部分。

现在，我也在考虑允许客户端使用 POST 创建对象：

POST /objects/ HTTP/1.1
...

{json representation of the object, including ID}

由于 POST 的意思是“追加”操作，如果对象已经存在，我不确定该怎么做。我应该将请求视为修改请求还是应该返回一些错误代码（哪个）？

【问题讨论】：

截至 2016 年 6 月，当电子邮件存在时，FB 在注册时公然设置 200
Github API 在尝试创建名称已被使用的资源（团队/仓库）时返回 422
这取决于您是否将对象的存在视为错误。如果您处理追加，则 200 或 204 是最合适的响应代码。
总而言之，它在 409 冲突和 422 无法处理的实体之间折腾 - 我认为这里答案的重要性指向 409，当然从人类的角度来看更容易理解
我使用 409 来处理这个问题，而 422 只用于糟糕的表单。

标签： rest http http-status-codes

【解决方案1】：

我的感觉是409 Conflict最合适不过，当然在野外很少见到：

由于与资源的当前状态冲突，请求无法完成。仅在预期用户可能能够解决冲突并重新提交请求的情况下才允许使用此代码。响应正文应该包含足够的信息让用户识别冲突的来源。理想情况下，响应实体将包含足够的信息供用户或用户代理解决问题；但是，这可能是不可能的，也不是必需的。

在响应 PUT 请求时最有可能发生冲突。例如，如果正在使用版本控制并且被 PUT 的实体包括对资源的更改，这些更改与早期（第三方）请求所做的更改相冲突，则服务器可能会使用 409 响应来指示它无法完成请求.在这种情况下，响应实体可能会以响应 Content-Type 定义的格式包含两个版本之间差异的列表。

【讨论】：

为什么不申请 400 Bad Request？对我来说，这看起来有点像验证错误（您提供的有效载荷是非法的）。
400 => “由于语法错误，服务器无法理解请求”。并且服务器完全理解，但由于冲突而无法遵守。请求和语法没有问题，只是数据问题。 400 会让我立即相信我使用的整个机制存在缺陷，而不仅仅是数据。
@Wrikken 这不再正确。 HTTP 400 在RFC 7231 中更改为表示“由于某些被认为是客户端错误（例如，格式错误的请求语法、无效请求），服务器无法或不会处理请求消息框架或欺骗性请求路由）。”我并不是说 400 在这种情况下是正确的用法，但它可能对于 400 的新定义是正确的。
@javajavajavajavajava：在我看来，重复数据不是“客户端错误”，但这当然是旁观者的看法。
我返回 HTTP 409 并带有一个指向现有/冲突资源的 Location 标头。

【解决方案2】：

我个人使用 WebDAV 扩展 422 Unprocessable Entity。

According to RFC 4918

422 Unprocessable Entity 状态码表示服务器理解请求实体的内容类型（因此415 Unsupported Media Type 状态码不合适），并且请求实体的语法是正确的（因此400 Bad Request 状态码是不合适）但无法处理包含的说明。

【讨论】：

这是一个有趣的想法，促使我最终阅读了 WebDAV RFC。但是，我认为 422 的含义是请求和包含的实体在语法上是正确的，但在语义上没有意义。
格式错误的 JSON 不是语法正确的实体，所以 422 让我觉得很奇怪......
我不会接受这个。来自答案中引用的同一 URL：“例如，如果 XML 请求正文包含格式正确（即语法正确）但语义错误的 XML 指令，则可能会发生此错误情况。”这是不可处理实体的真正含义，与您发送具有有效语法和语义的完全有效请求实体的情况不同，但唯一的问题是它与现有实体冲突。 实际上，如果请求实体的语义无效，则根本不应该存在类似的现有实体。
添加到 Tamer 评论中，如果第二个请求首先出现，那么它会成功，如果这在语义上是正确的，这是不可能的。因此，正确的语义在这里不适用。
@Tamer 为什么会这样？命令“请创建对象 xy”在语法上是正确的。只有当可以创建对象 xy 时，它才是语义正确的。如果对象 xy 已经存在，则无法再创建它，因此这是一个语义错误。

【解决方案3】：

“302 Found”对我来说听起来合乎逻辑。 RFC 2616 表示它可以回答 GET 和 HEAD 以外的其他请求（这肯定包括 POST）

但它仍然让访问者通过 RFC 访问此 URL 以获取此“找到”资源。要使其直接转到真正的“找到”URL，应该使用“303 See Other”，这是有道理的，但会强制另一个调用 GET 其以下 URL。从好的方面来说，这个 GET 是可缓存的。

我认为我会使用“303 See Other”。我不知道我是否可以用在正文中找到的“东西”来响应，但我想这样做以节省到服务器的一次往返。

更新：重新阅读RFC后，我仍然认为不存在“4XX+303 Found”代码应该是正确的。但是，“409 Conflict”是现有的最佳答案代码（由@Wrikken 指出），可能包括指向现有资源的 Location 标头。

【讨论】：

3xx 状态用于重定向
"请求的资源临时驻留在不同的 URI 下。"来自w3.org/Protocols/rfc2616/rfc2616-sec10.html
恕我直言，“307 临时重定向”是真正的临时重定向。 “302”是模棱两可的，但是“FOUND！！”是这里真正想要的信息。最好的明确折衷方案是 HTTP 语义上的“303 See Other”。 我会选择“303 See Other”。
@DavidVartanian Hum... 我在这里没有看到错误。客户端发送了一个正确的请求，但是如何说“对不起，但是您在这里尝试创建的内容已经存在于那里”？似乎是一些 3xx 的工作。这对我来说不是 4xx，因为没有客户端错误。
@DavidVartanian 感谢您的讨论。 更新了 409 的答案。客户要求不可能的东西是错误的，即使它不知道这是不可能的。

【解决方案4】：

我认为你不应该这样做。

如您所知，POST 用于修改集合，它用于创建新项目。所以，如果你发送id（我认为这不是一个好主意），你应该修改集合，即修改item，但它是混乱的。

用它来添加一个项目，没有 id。这是最好的做法。

如果您想捕获一个 UNIQUE 约束（而不是 id），您可以响应 409，就像您在 PUT 请求中所做的那样。但不是 ID。

【讨论】：

一个有连接表关系的对象呢？假设我们有 account、product 和 account_product 作为数据库表。我想将产品添加到帐户，因此我想使用 product_id 发布到 /account/{id}/product。如果只允许一种账户-产品关系，我应该返回什么？
忘记数据库表。假设一个产品只能与一个帐户相关......那么它就是一对多的关系。因此，使用 {'account':account_id} 发布 /product/{id}。如果您将最大基数设置为“1”（一对一关系）......为什么它们分开休息对象？基数错误只是 400 错误。把事情简单化。我希望我能理解你的问题。
我刚刚也提出了这个问题，对我来说，ID 不是数据库上的技术 ID，而是公司代码之类的东西。在这个应用程序中，经理用户可以创建公司并且必须给他们一个代码。这是用户的公司 ID，尽管 DB 表也有技术 ID。所以在我的情况下，如果相同的公司代码已经存在，我将返回 409。
@partkyle 停止使用 PK 作为公共 ID！
一些实体对它们有唯一的约束，而不仅仅是 id。与帐户一样，如果用户不提供用户名，则无法创建帐户。而且添加一个没有用户名的帐户显然是不可能的

【解决方案5】：

208 - http://httpstatusdogs.com/208-already-reported 怎么样？这是一个选项吗？

在我看来，如果唯一的事情是重复资源，则不应引发错误。毕竟，无论是客户端还是服务器端都没有错误。

【讨论】：

这不是选项，因为您想附加某个 id 已经存在的项目。所以你尝试添加一些东西，但它已经存在了。仅当数据集增长时才适用。附加一些东西-> 好的，我什么也没附加。不适合，我猜。
正如我所说，我不认为这是一个错误。但我看到了@martin 的意义
如果资源没有成功创建，则定义为错误。
POST 也用于附加数据。这是根据定义，不是错误。
@Suncat2000 即使是这样，如果数据没有成功追加，仍然有错误。如果资源已经存在，则不会追加任何数据。

【解决方案6】：

毕竟，另一种潜在的治疗方法是使用 PATCH。 PATCH 被定义为改变内部状态的东西，不限于追加。

PATCH 将通过允许您更新现有项目来解决问题。见：RFC 5789: PATCH

【讨论】：

Patch 类似于 PUT，但不是完全替代品。它用于修改资源的一部分，例如添加、删除或修改资源的单个元素，而不是整体替换它。

【解决方案7】：

也许游戏晚了，但我在尝试制作 REST API 时偶然发现了这个语义问题。

为了扩展 Wrikken 的回答，我认为您可以根据具体情况使用 409 Conflict 或 403 Forbidden - 简而言之，当用户完全无法解决冲突并完成请求（例如，他们不能发送DELETE 请求来显式删除资源），或者如果可以完成某些事情，则使用 409。

10.4.4 403 Forbidden

服务器理解请求，但拒绝执行。授权将无济于事，并且不应重复请求。如果请求方法不是 HEAD 并且服务器希望公开为什么请求没有被满足，它应该描述原因对于实体的拒绝。如果服务器不想让此信息可供客户端使用，状态码 404（不 Found) 可以代替。

现在，有人说“403”并且想到了权限或身份验证问题，但规范说它基本上是服务器告诉客户端它不会这样做，不要再问它，这就是原因客户不应该。

至于PUT 与POST...POST 应该用于在用户无法或不应该为资源创建标识符时创建资源的新实例。当资源的身份已知时使用PUT。

9.6 PUT

...

POST 和 PUT 请求的根本区别在于体现在Request-URI的不同含义上。 URI 中的 POST 请求标识将处理封闭的资源实体。该资源可能是一个数据接受过程，一个通往一些其他协议，或接受注释的单独实体。在相反，PUT 请求中的 URI 标识用请求——用户代理知道 URI 的意图和服务器不得尝试将请求应用于其他资源。如果服务器希望将请求应用于不同的 URI，

它必须发送 301（永久移动）响应；用户代理可以然后自行决定是否重定向请求。

【讨论】：

我认为 403 Forbidden 意味着，即使用户被认证，他也没有被授权执行请求的动作。我不会将它用于验证错误。示例：未登录，我尝试删除某些内容。服务器向我发送 401 Unauthorized（只是名称错误，应该是 401 Unauthenticated）。我登录并重试。这次服务器检查我的权限，发现我不允许并返回 403 Forbidden。另见this question。
嗯...是的。这里的想法是直接告诉用户他们的授权使资源在 OP 的用例中不可变 - 它已经存在，您无权做任何事情来解决冲突，不要尝试再次创建资源。
根据规范，暗示错误 409 不能由 POST 请求返回（如果使用正确），因为它指出当它与 冲突时应该返回目标资源。由于目标资源尚未发布，不可能发生冲突，因此回复409 Conflict没有任何意义。
我不会推断 POST 不能返回 409 错误，事实上，我会推断相反，因为“冲突是最有可能在响应中发生到 PUT 请求。”似乎表明其他请求方法也可以使用此代码。此外，“响应正文应该包含足够的信息，以便用户识别冲突的来源。理想情况下，响应实体将包含足够的信息，以便用户或用户代理解决问题；但是，这可能是不可能的，并且不需要。” (webdav.org/specs/rfc2616.html#status.409)

【解决方案8】：

为什么不202 Accepted？这是一个 OK 请求（200 秒），本身没有客户端错误（400 秒）。

来自10 Status Code Definitions：

“202 Accepted。请求已被接受处理，但处理尚未完成。”

...因为它不需要完成，因为它已经存在。客户不知道它已经存在，他们没有做错任何事。

我倾向于抛出 202，并返回与 GET /{resource}/{id} 将返回的内容相似的内容。

【讨论】：

这个答案是错误的。 202表示服务器没有发现请求有问题，而是选择响应后处理请求。这也意味着它期望处理成功。在我们的例子中，服务器知道处理会失败，所以 202 是错误的响应。
202 的示例是队列或订阅。换句话说，如果您此时要查询，请求的结果可能不会立即可用。
如果服务器仍在处理请求，这将是合适的。 200 或 204 会更常见。由于 OP 正在发出追加请求，因此对象的存在是预期条件而不是错误。
向客户说请求被接受是没有意义的，因为您已经知道它不是！
@Adrian 和 lucastamoios 我认为你们都假设服务器在提供响应之前同步地从数据库中读取数据。情况并非总是如此，所以这个答案不是“错误的”，因为服务器并不总是“知道”现有记录。这在异步系统中非常常见，其中 api 层只是记录后台工作人员处理的请求。

【解决方案9】：

我认为对于 REST，您只需决定该特定系统的行为，在这种情况下，我认为“正确”的答案将是这里给出的几个答案之一。如果您希望请求停止并表现得好像客户端犯了一个需要在继续之前修复的错误，则使用 409。如果冲突确实不那么重要并且希望继续请求，则通过重定向来响应客户到找到的实体。我认为适当的 REST API 应该在 POST 之后重定向（或至少提供位置标头）到该资源的 GET 端点，因此这种行为将提供一致的体验。

编辑：还值得注意的是，由于您提供了 ID，因此您应该考虑使用 PUT。然后行为很简单：“我不管现在有什么，把这个东西放在那里。”意思是，如果什么都没有，它将被创建；如果有东西，它将被替换。我认为当服务器管理该 ID 时，POST 更合适。分离这两个概念基本上告诉您如何处理它（即 PUT 是幂等的，因此只要有效负载验证它就应该始终工作，POST 总是创建，因此如果 ID 发生冲突，则 409 将描述该冲突） .

【讨论】：

根据规范，暗示POST请求不能返回错误409（正确使用时），因为它指出当它与冲突时应该返回目标资源。由于目标资源尚未发布，不可能发生冲突，因此回复409 Conflict没有任何意义。
有争议的 imo。如果您发布到 /users 则资源是集合而不是单个记录 /users/{id}
当存储的资源版本和请求的资源版本冲突时，专门针对版本控制的错误。它对此非常有用，例如，当客户端缓存了资源的旧版本并基于不再有条件有效的不正确版本发送请求时。 “在这种情况下，响应表示可能包含有助于根据修订历史合并差异的信息。”
我很喜欢你使用PUT的建议。

【解决方案10】：

根据RFC 7231，可以使用 303 See Other 如果处理 POST 的结果相当于现有资源的表示。

【讨论】：

在我看来，这可能是公认的答案。虽然“MAY”表示完全可选项目，但它是RFC 7231官方文档建议的唯一响应代码。
这是最 RESTful 的答案。
我认为上下文很重要。例如：返回 303 意味着需要重定向到找到的资源。这在服务器到服务器调用中可能有意义，但如果您正在运行用户注册过程，则根本没有意义。
对不起，我反对这个。 HTTP 300 是关于重定向的，而重定向到可能具有不同属性的另一个对象会非常具有误导性。
您不必感到抱歉。但是，如果表示等同于现有资源，它怎么会有不同的属性呢？即使它有，重定向如何误导？ OP 说：如果对象已经存在，我不确定该怎么做。 它实际上是“相同的”对象。为什么重定向会产生误导？您说的是 另一个对象，在 OP 的脑海中显然不是。

【解决方案11】：

在检查重复记录的正确代码时偶然发现了这个问题。

请原谅我的无知，但我不明白为什么每个人都忽略了代码“300”，其中明确表示“多项选择”或“模棱两可”

在我看来，这将是构建非标准或特定系统供您自己使用的完美代码。我也可能是错的！

https://www.rfc-editor.org/rfc/rfc7231#section-6.4.1

【讨论】：

我的理解：“状态码表明目标资源具有不止一种表示形式……正在提供有关替代方案的信息，以便用户（或用户代理）可以通过重定向选择首选表示形式它对这些标识符中的一个或多个的请求”我们明确地试图阻止一种以上的表示。没有选项。客户没有其他选择。客户应使用不同的 ID 重新提交。话虽如此，还应该考虑是否应该在客户端和服务器中生成唯一 ID。
从语义上讲，客户端在说“创建这个”，而服务器通过说“改为转到这里”来响应。谈话没有任何意义。就好像服务器告诉客户端“改为发布到这个位置”。在服务器响应“好的，我创建了它，它在这里结束”的情况下，300 更适合对 GET 请求或 POST 的响应..

【解决方案12】：

我会选择422 Unprocessable Entity，当请求无效但问题不在语法或身份验证时使用。

作为反对其他答案的论据，使用任何非4xx 错误代码都意味着它不是客户端错误，而且显然是。使用非4xx 错误代码来表示客户端错误完全没有意义。

409 Conflict 似乎是这里最常见的答案，但根据规范，这意味着资源已经存在并且您应用到它的新数据与其当前状态不兼容。如果您发送POST 请求，例如，用户名已被占用，它实际上并没有与目标资源冲突，因为目标资源（您尝试创建的资源）尚未发布.当存储的资源版本与请求的资源版本之间存在冲突时，这是专门针对版本控制的错误。这对于该目的非常有用，例如，当客户端缓存了资源的旧版本并基于不再有条件有效的不正确版本发送请求时。 “在这种情况下，响应表示可能包含有助于根据修订历史合并差异的信息。”使用该用户名创建另一个用户的请求是无法处理的，与任何版本冲突无关。

作为记录，422 也是 GitHub 在您尝试使用已在使用的名称创建存储库时使用的状态代码。

【讨论】：

422 是 webdav 规范，所以我不建议将它用于 REST API
@rwenz3l 为什么不呢？它相当传统，清楚地符合目的，并且传达了它的意图。

【解决方案13】：

更有可能是400 Bad Request

[**6.5.1. 400 错误请求**][1]

400（Bad Request）状态码表示服务器不能或由于某些被认为是客户端错误（例如，格式错误的请求语法、无效请求消息框架或欺骗性请求路由）。

由于请求包含重复值（已存在的值），它可以被视为客户端错误。需要在下次尝试之前更改请求。
通过考虑这些事实，我们可以得出 HTTP STATUS 400 Bad Request 的结论。

【讨论】：

Bad Request 表示数据包的语法存在固有问题。如果在另一个上下文中（例如资源不存在），数据包会成功，那么它不应该返回错误 400。

【解决方案14】：

这一切都与上下文有关，以及谁负责处理请求中的重复项（服务器或客户端或两者）

如果服务器只是指向重复项，请查看 4xx：

400 Bad Request - 当服务器因为明显的客户端故障而不会处理请求时
409 冲突 - 如果服务器不会处理请求，但原因不是客户端的错误
...

对于重复的隐式处理，请查看 2XX：

200 正常
201 创建
...

如果服务器预计会返回一些东西，请查看 3XX：

302 找到
303 查看其他
...

当服务器能够指向现有资源时，它意味着重定向。

如果以上内容还不够，最好在响应正文中准备一些错误消息。

【讨论】：

请求不是复制资源，而是将数据附加到一个资源。在我看来，你的答案是最好的。
所有 4xx 错误都是客户端的“错误”。所有 5xx 错误都是服务器的“故障”。（提交重复数据是客户端必须解决的问题，而不是服务器。）
@Paul Draper：当资源已经存在时，没有 5xx 的位置。 4xx、2xx、3xx的顺序在这里并不是巧合。它主要是 4xx，但在许多情况下其他的就足够了，尤其是当客户完全不知道如何处理重复或根本不重要时。

【解决方案15】：

在您的情况下，您可以使用409 Conflict

如果你想从下面的列表中检查另一个HTTPs 状态代码

1×× 信息性

100 Continue
101 Switching Protocols
102 Processing

2××成功

200 OK
201 Created
202 Accepted
203 Non-authoritative Information
204 No Content
205 Reset Content
206 Partial Content
207 Multi-Status
208 Already Reported
226 IM Used

3××重定向

300 Multiple Choices
301 Moved Permanently
302 Found
303 See Other
304 Not Modified
305 Use Proxy
307 Temporary Redirect
308 Permanent Redirect

4×× 客户端错误

400 Bad Request
401 Unauthorized
402 Payment Required
403 Forbidden
404 Not Found
405 Method Not Allowed
406 Not Acceptable
407 Proxy Authentication Required
408 Request Timeout
409 Conflict
410 Gone
411 Length Required
412 Precondition Failed
413 Payload Too Large
414 Request-URI Too Long
415 Unsupported Media Type
416 Requested Range Not Satisfiable
417 Expectation Failed
418 I’m a teapot
421 Misdirected Request
422 Unprocessable Entity
423 Locked
424 Failed Dependency
426 Upgrade Required
428 Precondition Required
429 Too Many Requests
431 Request Header Fields Too Large
444 Connection Closed Without Response
451 Unavailable For Legal Reasons
499 Client Closed Request

5×× 服务器错误

500 Internal Server Error
501 Not Implemented
502 Bad Gateway
503 Service Unavailable
504 Gateway Timeout
505 HTTP Version Not Supported
506 Variant Also Negotiates
507 Insufficient Storage
508 Loop Detected
510 Not Extended
511 Network Authentication Required
599 Network Connect Timeout Error

【讨论】：

【解决方案16】：

这是用户端故障，属于 4xx 组。这是正确答案https://developers.rebrandly.com/docs/403-already-exists-errors

【讨论】：

403 被禁止
你是对的@selalerer，客户端被禁止执行操作（添加相同的资源）
这不是错误代码定义的权威来源，它是 their their 代码定义列表their API。

【解决方案17】：

错误 402，需要付款

I.E.这个资源已经存在，但如果你给我足够的钱，我会删除当前的资源并给你：D

...但是在https://developer.mozilla.org/en-US/docs/Web/HTTP/Status#client_error_responses查看 Mozilla 对状态代码的定义

作为一个没有人在这里提供的更严肃的答案，451 怎么样：由于法律原因不可用。您不能“合法地（根据您自己制定的条款和条件）”让多个人访问同一帐户信息

422 也是一个不错的选择，它是不可处理的实体该请求格式正确，但由于语义错误而无法执行。因为它是一个完全有效的请求，但由于它在语义上等于另一个条目，所以不能被遵循。

【讨论】：

哈哈哈，我喜欢这个！

【解决方案18】：

在阅读了本文和其他数年关于状态码使用的讨论之后，我得出的主要结论是必须仔细阅读规范，重点关注所使用的术语、它们的定义、关系以及周围的环境。

从不同的答案中可以看出，经常发生的情况是，规范的某些部分脱离了上下文，并根据感觉和假设进行了孤立的解释。

这将是一个很长的答案，简短的总结是 HTTP 409 是报告“添加新资源”操作失败的最合适的状态代码，以防资源具有相同的标识符已经存在。以下是原因的解释，仅基于权威来源 - RFC 7231 中所述的内容。

那么为什么409 Conflict 在 OP 的问题中描述的情况下是最合适的状态代码？

RFC 7231 描述409 Conflict 状态码如下：

409（冲突）状态码表示由于与目标资源的当前状态冲突，请求无法完成。

这里的关键组件是目标资源及其状态。

目标资源

资源由 RFC 7231 定义如下：

HTTP 请求的目标称为“资源”。 HTTP 不限制资源的性质；它仅仅定义了一个可以用来与资源交互的接口。每个资源都由统一资源标识符 (URI) 标识，如 [RFC7230] 的第 2.7 节所述。

因此，当使用 HTTP 接口时，我们总是通过对 URI 标识的资源应用 HTTP 方法来操作它们。

当我们打算添加新资源时，根据 OP 的示例，我们可以：

将PUT 与资源/objects/{id} 一起使用；
将POST 与资源/objects 一起使用。

/objects/{id} 不感兴趣，因为使用PUT 方法时不会发生冲突：

PUT 方法请求将目标资源的状态创建或替换为请求消息负载中包含的表示所定义的状态。

如果相同标识符的资源已经存在，则替换为PUT。

所以我们将关注/objects 资源和POST。

RFC 7231 提到了POST：

POST 方法请求目标资源根据资源自己的特定语义处理请求中包含的表示。例如，POST 用于以下功能（以及其他功能）： ... 3）创建尚未被源服务器识别的新资源；和 4) 将数据附加到资源的现有表示中。

与 OP 如何理解 POST 方法相反：

由于 POST 的意思是“追加”操作...

将数据附加到资源的现有表示只是可能的POST“功能”之一。此外，OP 在提供的示例中实际上所做的并不是直接将数据附加到/objects 表示，而是创建一个新的独立资源/objects/{id}，然后成为/objects 表示的一部分。但这并不重要。

重要的是资源表示的概念，它使我们...

资源状态

RFC 7231 解释：

考虑到资源可以是任何东西，并且 HTTP 提供的统一接口类似于一个窗口，通过该窗口，人们只能通过与另一端的某个独立参与者进行消息通信来观察和操作此类事物，需要一个抽象来表示（“代替”）我们通信中该事物的当前或期望状态。这种抽象称为表示 [REST]。

就 HTTP 而言，“表示”是旨在反映给定资源的过去、当前或期望状态的信息，其格式可以通过协议轻松通信，并且包含一组表示元数据和一个潜在的无限表示数据流。

这还不是全部，规范继续描述表示部分 - 元数据和数据，但我们可以总结由元数据（标头）和数据（有效负载）组成的资源表示反映了资源的状态。

现在我们已经掌握了了解409 Conflict 状态码用法所需的两个部分。

409 冲突

让我们重申一下：

409（冲突）状态码表示由于与目标资源的当前状态冲突，请求无法完成。

那么它是如何适合的呢？

我们POST 到/objects => 我们的目标资源是/objects。
OP 没有描述/objects 资源，但该示例看起来像是一个常见场景，其中/objects 是一个资源集合，包含所有单独的“对象”资源。也就是说，/objects 资源的状态包括关于所有现有/object/{id} 资源的知识。
当/objects 资源处理POST 请求时，它必须 a) 从请求有效负载中传递的数据创建一个新的/object/{id} 资源； b) 通过添加有关新创建资源的数据来修改自己的状态。
当要创建的资源有重复标识符，即已经存在具有相同/object/{id} URI 的资源时，/objects 资源将无法处理POST 请求，因为它的状态已经包含重复的/object/{id} URI 在里面。

这正是与目标资源当前状态的冲突，在409 Conflict状态码描述中提到。

【讨论】：