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

根据RFC 4918

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

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).

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

在我看来，如果唯一的东西是重复资源，就不应该引发错误。毕竟，客户端和服务器端都没有错误。

我会选择422不可处理实体，当请求无效时使用，但问题不在于语法或身份验证。

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

It seems that 409 Conflict is the most common answer here, but, according to the spec, that implies that the resource already exists and the new data you are applying to it is incompatible with its current state. If you are sending a POST request, with, for example, a username that is already taken, it's not actually conflicting with the target resource, as the target resource (the resource you're trying to create) has not yet been posted. It's an error specifically for version control, when there is a conflict between the version of the resource stored and the version of the resource requested. It's very useful for that purpose, for example when the client has cached an old version of the resource and sends a request based on that incorrect version which would no longer be conditionally valid. "In this case, the response representation would likely contain information useful for merging the differences based on the revision history." The request to create another user with that username is just unprocessable, having nothing to do with any version conflict.

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

由于您提到使用post的对象创建请求包含对象的ID，因此应该使其成为幂等请求。只返回与成功创建请求完全相同的响应。幂等请求使api更简单，例如。现在客户不必担心两种不同的情况(成功，失败)。或者客户端可以安全地重试请求，以防在连接/服务器暂时宕机时出现问题。

根据RFC 7231，如果POST处理的结果等同于 现有资源的表示。