我正在构建一个允许客户端存储对象的服务器。这些对象是在客户端完全构造的，对象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意味着“追加”操作，我不确定在对象已经存在的情况下该做什么。我应该把请求作为修改请求，还是应该返回一些错误代码(哪个)?
当前回答
根据RFC 7231，如果POST处理的结果等同于 现有资源的表示。
其他回答
另一个潜在的治疗方法是使用PATCH。PATCH被定义为改变内部状态的东西，不局限于追加。
PATCH将通过允许您更新已经存在的项目来解决这个问题。参见:RFC 5789: PATCH
我会选择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使用的状态码，当您尝试按已使用的名称创建存储库时。
208- http://httpstatusdogs.com/208-already-reported怎么样?这是一个选择吗?
在我看来，如果唯一的东西是重复资源，就不应该引发错误。毕竟，客户端和服务器端都没有错误。
根据RFC 7231，如果POST处理的结果等同于 现有资源的表示。
用户侧故障，属于4xx组。这是正确答案https://developers.rebrandly.com/docs/403-already-exists-errors
