我正在构建一个允许客户端存储对象的服务器。这些对象是在客户端完全构造的，对象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意味着“追加”操作，我不确定在对象已经存在的情况下该做什么。我应该把请求作为修改请求，还是应该返回一些错误代码(哪个)?
当前回答
错误402，需要付款
例如，这个资源已经存在，但如果你给我足够的钱，我会删除当前的一个，给你:D
.．.但是看看mozilla在https://developer.mozilla.org/en-US/docs/Web/HTTP/Status#client_error_responses上对状态码的定义
作为一个更严肃的答案，这里没有人提供，那451呢:由于法律原因无法使用。你不能“合法地(通过你自己制定的条款和条件)”让多人访问相同的帐户信息
422也是一个很好的选择，它是不可处理的实体 请求格式良好，但由于语义错误而无法执行。由于它是一个完全有效的请求，但由于它在语义上与另一个条目相等，所以不能遵循它。
其他回答
“302 Found”对我来说听起来合乎逻辑。RFC 2616说除了GET和HEAD之外，它还可以被其他请求回答(当然也包括POST)
但是它仍然让访问者通过RFC访问这个URL来获得这个“已找到”的资源。为了使它直接指向真正的“Found”URL，应该使用“303 See Other”，这是有意义的，但强制另一个调用GET它后面的URL。好的方面是，这个GET是可缓存的。
我想我会用“303 See Other”。我不知道我是否可以响应在主体中发现的“东西”，但我想这样做，以节省到服务器的一次往返。
更新:在重新阅读RFC后，我仍然认为不存在的“4XX+303 Found”代码应该是正确的。然而，“409冲突”是现有的最好的答案代码(正如@ wrkken指出的那样)，可能包括指向现有资源的Location头。
就我个人而言，我倾向于WebDAV扩展422不可处理实体。
根据RFC 4918
422不可处理实体状态码意味着服务器理解请求实体的内容类型(因此415不支持的媒体类型状态码是不合适的)，并且请求实体的语法是正确的(因此400坏请求状态码是不合适的)，但无法处理包含的指令。
根据RFC 7231，如果POST处理的结果等同于 现有资源的表示。
用户侧故障，属于4xx组。这是正确答案https://developers.rebrandly.com/docs/403-already-exists-errors
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).
