我正在构建一个服务器，允许客户端存储对象。这些对象在客户端完全构造，包括对象ID在内，而这些ID对于对象的整个生命周期都是固定的。
我已经定义了API，使得客户端可以使用PUT创建或修改对象：
PUT /objects/{id} HTTP/1.1
...
{json representation of the object}
{id}是对象的ID，因此它是请求URI的一部分。
现在，我还考虑允许客户端使用POST创建该对象：
POST /objects/ HTTP/1.1
...
{json representation of the object, including ID}
由于POST是“追加”操作，如果对象已经存在，我不确定该怎么办。 我应该将请求视为修改请求还是返回某些错误代码（哪个）？
我认为409冲突是最合适的状态码，但在实际应用中很少见到：
由于与资源当前状态存在冲突，请求无法完成。该状态码仅在预期用户可能能够解决冲突并重新提交请求的情况下使用。响应正文应包含足够的信息，以便用户识别冲突的源头。最理想的情况是响应实体包含足够的信息供用户或用户代理程序修复问题；然而，这可能是不可能的，也不是必需的。
PUT请求最有可能导致冲突。例如，如果正在使用版本控制，并且被PUT的实体包括与先前（第三方）请求所做的更改相冲突的更改，则服务器可能使用409响应来指示无法完成请求。在这种情况下，响应实体可能会以响应Content-Type定义的格式列出两个版本之间的差异列表。
HTTP 409 状态码，并在响应头中添加 Location，指向已经存在或发生冲突的资源。 - Gili这一切都与上下文有关，以及谁负责处理请求的重复（服务器、客户端或两者都有）
如果服务器仅指出重复，请查看4xx：
对于隐含的重复处理，请查看2XX：
如果服务器期望返回某些内容，请查看3XX：
当服务器能够指向现有资源时，它意味着重定向。
如果以上还不够，准备一些错误信息放在响应体中始终是一个好习惯。
个人而言，我会选择使用WebDAV扩展 422 Unprocessable Entity。
422 Unprocessable Entity状态码表示服务器理解请求实体的内容类型（因此，415 Unsupported Media Type状态码不合适），并且请求实体的语法正确（所以，400 Bad Request状态码不合适），但无法处理其中包含的指令。
422状态码让我感到奇怪... - awendt409 Conflict是最合适的状态码呢？409 Conflict状态码描述如下：/objects/{id}的PUT；
- 使用具有资源/objects的POST。
/objects/{id}不感兴趣，因为使用PUT方法时不可能发生冲突：PUT。/objects资源和POST上。POST的说法：/objects 发送 POST 请求 => 我们的目标资源是 /objects。/objects 资源，但示例看起来像是一个常见的情况，其中 /objects 是一个资源集合，包含所有单独的 "object" 资源。也就是说，/objects 资源的 状态 包括了所有现有的 /object/{id} 资源的信息。/objects 资源处理 POST 请求时，它需要 a) 根据请求负载中传递的数据创建一个新的 /object/{id} 资源；b) 通过添加有关新创建资源的数据来修改自己的状态。/object/{id} URI 的资源时，/objects 资源将无法处理 POST 请求，因为其状态已经包含了重复的 /object/{id} URI。这正是 409 Conflict 状态码描述中提到的与目标资源当前状态的冲突。
我会选择422 Unprocessable Entity，用于在请求无法被处理但问题不在语法或身份验证方面时使用，请参见RFC 9110：
422（无法处理的内容）状态码表示服务器理解请求内容的内容类型（因此，415（不支持的媒体类型）状态码不合适），并且请求内容的语法是正确的，但是它无法处理包含的指令。例如，如果XML请求内容包含形式良好（即语法上正确），但语义上错误的XML指令，则可以发送此状态代码。
作为反对其他答案的论据，使用任何非4xx错误代码都将意味着这不是客户端错误，而显然是。没有符合规范的理由使用非4xx错误代码来表示客户端错误。
看起来409 Conflict是最常见的答案，但是根据规范，这意味着资源已经存在，您请求的操作与其当前状态不兼容。如果您发送一个POST请求，例如使用已经被占用的用户名，它实际上并没有与目标资源冲突，因为目标资源（您正在尝试创建的资源）甚至还不存在。这主要是版本控制的错误，当存储的资源版本与客户端在其请求中假定的资源版本之间存在冲突时。
值得一提的是，当您尝试创建一个已经存在的仓库名称时，GitHub也会使用422作为状态码。
编辑：HTTP现在通过RFC 9110将错误422标准化了！它不再只是WebDAV的一部分。
在阅读新的RFC 9110时，我意识到我以前对错误409的解释是错误的。
409（冲突）状态码表示由于目标资源的当前状态与请求存在冲突，无法完成请求。在用户可能解决冲突并重新提交请求的情况下使用此代码。服务器应生成包含足够信息的内容，以便用户能够识别冲突的来源。关于错误代码409的充分论据，请参见this answer。简而言之，有冲突的“目标资源”实际上是您要发布的资源集合，而不是您正在创建的资源，这是符合规范的解释（该答案详细阐述了原因）。如果您同意该答案，请为其点赞，而非本答案！
（注：我改变主意时我的投票数为31，因此现在这个答案有多少更多/更少的投票应该有助于衡量多少人仍然同意/不同意我的旧答案，尽管我已经进行了编辑。）
也许我有些晚了，但在尝试创建REST API时，我遇到了这个语义问题。
稍微解释一下Wrikken的答案，我认为你可以根据情况使用409 Conflict或403 Forbidden - 简而言之，当用户无法采取任何措施来解决冲突并完成请求（例如他们无法发送DELETE请求显式删除资源）时，请使用403错误，否则如果可能有所作为，则使用409。
现在，当有人说“403”时，会想到权限或身份验证问题，但规范表明这基本上是服务器告诉客户端它不会执行请求，不要再问了，并且这是为什么客户端不应该这样做。10.4.4 403 Forbidden
服务器理解请求，但拒绝执行它。授权不会有帮助，请求不应重复。如果请求方法不是HEAD，并且服务器希望公开说明未能满足请求的原因，则应在实体中描述拒绝的原因。如果服务器不希望向客户端提供此信息，则可以使用状态代码404（未找到）代替。
...
POST和PUT请求的根本区别在于Request-URI的不同含义。POST请求中的URI标识将处理所包含实体的资源，该资源可能是数据接受进程、其他协议的网关或接受注释的单独实体。相比之下，PUT请求中的URI标识了请求中所包含的实体，用户代理知道要使用哪个URI，服务器不得尝试将请求应用于其他资源。如果服务器希望将请求应用于不同的URI，则必须发送301（永久移动）响应；然后用户代理可以自行决定是否重定向请求。
POST请求不会返回错误409（冲突错误）。规范指出在与“目标资源”发生冲突时才应该返回此错误码。因为目标资源尚未被提交，所以它不可能发生冲突，因此回复409 Conflict毫无意义。 - Grant GryczanPOST 返回，事实上，我会推断相反的是因为 "冲突最有可能发生在对 PUT 请求的响应中。" 似乎表明其他请求方法也可以使用这个代码。 另外，"响应正文 应该 包含足够的信息，让用户识别冲突的来源。理想情况下，响应实体将包括足够的信息，让用户或用户代理程序修复问题；然而，这可能是不可能的，并且是 不必要的。" (http://www.webdav.org/specs/rfc2616.html#status.409) - JWAspin在您的情况下，您可以使用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
我认为你不应该这样做。
正如您所知，POST用于修改集合，并用于创建新项。因此，如果您发送ID（我认为这不是一个好主意），则应该修改集合，即修改该项，但这会令人困惑。
最佳实践是使用它来添加一个没有ID的项目。
如果您想捕获唯一约束（而不是ID），则可以像PUT请求中那样响应409。但不要使用ID。
POST /managers 添加或替换 PUT /managers/{id} 将员工添加到经理 POST /managers/{id}/direct-reports 添加或替换员工 PUT /managers/{id}/direct-reports/{id} 等。其余部分（例如约束）是验证。1:1关系和部分更新可以以相同的方式处理，或作为单个属性进行PATCH。如果需要多个步骤，则使用多个步骤，例如 POST /users，然后是 POST /managers/{id}/direct-reports/{user-id-returned-by-previous-call}。 - Sinaesthetic