当资源已经存在时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意味着“追加”操作，我不确定在对象已经存在的情况下该做什么。我应该把请求作为修改请求，还是应该返回一些错误代码(哪个)?

当前回答

就我个人而言，我倾向于WebDAV扩展422不可处理实体。

根据RFC 4918

422不可处理实体状态码意味着服务器理解请求实体的内容类型(因此415不支持的媒体类型状态码是不合适的)，并且请求实体的语法是正确的(因此400坏请求状态码是不合适的)，但无法处理包含的指令。

2010-09-29 21:44:38

其他回答

我的感觉是409冲突是最合适的，但是，在野外当然很少见到:

The request could not be completed due to a conflict with the current state of the resource. This code is only allowed in situations where it is expected that the user might be able to resolve the conflict and resubmit the request. The response body SHOULD include enough information for the user to recognize the source of the conflict. Ideally, the response entity would include enough information for the user or user agent to fix the problem; however, that might not be possible and is not required. Conflicts are most likely to occur in response to a PUT request. For example, if versioning were being used and the entity being PUT included changes to a resource which conflict with those made by an earlier (third-party) request, the server might use the 409 response to indicate that it can't complete the request. In this case, the response entity would likely contain a list of the differences between the two versions in a format defined by the response Content-Type.

2010-09-29 21:31:13

I think for REST, you just have to make a decision on the behavior for that particular system in which case, I think the "right" answer would be one of a couple answers given here. If you want the request to stop and behave as if the client made a mistake that it needs to fix before continuing, then use 409. If the conflict really isn't that important and want to keep the request going, then respond by redirecting the client to the entity that was found. I think proper REST APIs should be redirecting (or at least providing the location header) to the GET endpoint for that resource following a POST anyway, so this behavior would give a consistent experience.

EDIT: It's also worth noting that you should consider a PUT since you're providing the ID. Then the behavior is simple: "I don't care what's there right now, put this thing there." Meaning, if nothing is there, it'll be created; if something is there it'll be replaced. I think a POST is more appropriate when the server manages that ID. Separating the two concepts basically tells you how to deal with it (i.e. PUT is idempotent so it should always work so long as the payload validates, POST always creates, so if there is a collision of IDs, then a 409 would describe that conflict).

2016-10-27 04:51:04

这完全取决于上下文，以及谁负责处理重复的请求(服务器或客户端或两者都有)

如果服务器只是指向副本，请查看4xx:

400坏请求——服务器不会处理一个请求，因为这是明显的客户端错误 409冲突——如果服务器不处理请求，但原因不是客户端的错 .．.

对于副本的隐式处理，请参阅2XX:

200好了 201年创建 .．.

如果服务器希望返回一些东西，请查看3XX:

302年发现的 303查看其他 .．.

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

如果以上还不够，那么在响应体中准备一些错误消息总是一个很好的做法。

2018-08-08 11:58:27

就我个人而言，我倾向于WebDAV扩展422不可处理实体。