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

我正在构建一个允许客户端存储对象的服务器。这些对象在客户端完全构建，并带有在对象整个生命周期中永久存在的对象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的意思是“追加”操作，因此我不确定在对象已经存在的情况下该怎么做。我应该将请求视为修改请求还是应该返回一些错误代码（哪个）？

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

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

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

根据RFC 7231，如果处理POST的结果等效于现有资源的表示形式，则可以使用303 See Other。

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

根据RFC 4918

的422 Unprocessable Entity状态代码装置的服务器理解的内容类型的请求实体（因此一个的415 Unsupported Media Type状态码是不适当的），并且请求实体的语法是正确的（因此一个400 Bad Request状态码是不适当的），但无法处理所包含的指令。

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

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

• 400错误的请求-服务器由于明显的客户端故障而无法处理请求时
• 409冲突-如果服务器不处理请求，但是原因不是客户端的错误
• ...

要隐式处理重复项，请查看2XX：

• 200 OK
• 创建了201
• ...

如果服务器期望返回某些内容，请查看3XX：

• 找到302个
• 303查看其他
• ...

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

如果以上还不够，在响应正文中准备一些错误消息始终是一个好习惯。

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

为了扩大Wrikken的回答一点，我想你可以使用两种409 Conflict或403 Forbidden视情况而定-简而言之，使用403错误时，用户可以什么都不做，解决冲突和完成请求（例如，它们不能发送DELETE请求以明确删除资源），或者在可能的情况下使用409。

10.4.4 403禁止

服务器理解了该请求，但拒绝执行该请求。授权将无济于事，并且不应重复该请求。如果请求方法不是HEAD，并且服务器希望公开为什么未满足请求，则应在实体中描述拒绝原因。如果服务器不希望将此信息提供给客户端，则可以改用状态代码404（未找到）。

如今，有人说“ 403”，然后想到权限或身份验证问题，但是规范说这基本上是服务器告诉客户端它不打算这样做，不要再询问，这就是客户端为什么不这样做的原因。没错

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

9.6放置

...

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

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

“ 302 Found”对我来说听起来很合逻辑。和RFC 2616说，它比GET和HEAD其他请求回答（这当然包括POST）

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

我认为我会使用“ 303 See Other”。我不知道我是否可以使用正文中找到的“内容”进行响应，但是我想这样做是为了节省一次往返服务器的时间。

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

我不认为你应该这样做。

如您所知，POST是用来修改集合的，它用于创建新项目。因此，如果您发送ID（我认为这不是一个好主意），则应该修改集合，即修改项目，但这会造成混淆。

使用它添加没有ID的项目。这是最佳做法。

如果要捕获UNIQUE约束（而不是id），则可以响应409，就像在PUT请求中一样。但不是ID。

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

作为反对其他答案的一个论据，使用任何非4xx错误代码将意味着它不是客户端错误，而显然是。要使用非4xx错误代码表示客户端错误根本没有任何意义。

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

记录一下，422也是GitHub尝试通过已经使用的名称创建存储库时使用的状态代码。

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

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

毕竟，另一种可能的治疗方法是使用PATCH。PATCH定义为可更改内部状态且不限于附加的内容。

PATCH通过允许您更新已经存在的项目来解决该问题。请参阅：RFC 5789：补丁

为什么不接受202？这是一个正常的请求（200s），本身没有客户端错误（400s）。

来自10个状态码定义：

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

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

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

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

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

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

https://tools.ietf.org/html/rfc7231#section-6.4.1

更有可能 400 Bad Request

6.5.1。400错误的要求

400（错误请求）状态代码表示服务器由于某些原因（例如格式错误的请求语法，无效的请求消息框架或欺骗性的请求路由）而被视为客户端错误，因此服务器无法处理该请求。

由于请求包含重复值（已经存在的值），因此可以将其视为客户端错误。下一次尝试之前，需要更改请求。
考虑到这些事实，我们可以得出HTTP STATUS 400错误请求的结论。

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

我认为，如果唯一的事情是重复资源，则不会出现任何错误。毕竟，客户端或服务器端都没有错误。