我正在构建一个允许客户端存储对象的服务器。这些对象是在客户端完全构造的，对象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也是一个很好的选择，它是不可处理的实体 请求格式良好，但由于语义错误而无法执行。由于它是一个完全有效的请求，但由于它在语义上与另一个条目相等，所以不能遵循它。
其他回答
由于您提到使用post的对象创建请求包含对象的ID，因此应该使其成为幂等请求。只返回与成功创建请求完全相同的响应。幂等请求使api更简单，例如。现在客户不必担心两种不同的情况(成功，失败)。或者客户端可以安全地重试请求，以防在连接/服务器暂时宕机时出现问题。
“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头。
在检查重复记录的正确代码时偶然发现了这个问题。
请原谅我的无知，但我不明白为什么每个人都忽略了代码“300”，它清楚地表示“多项选择”或“模棱两可”
在我看来，这将是构建非标准或特定系统供自己使用的完美代码。我也可能是错的!
https://www.rfc-editor.org/rfc/rfc7231#section-6.4.1
在您的情况下，您可以使用409冲突
如果你想检查另一个HTTPs状态码从下面的列表
1××信息
100 Continue
101 Switching Protocols
102 Processing
2××成功
200 OK
201 Created
202 Accepted
203 Non-authoritative Information
204 No Content
205 Reset Content
206 Partial Content
207 Multi-Status
208 Already Reported
226 IM Used
3××重定向
300 Multiple Choices
301 Moved Permanently
302 Found
303 See Other
304 Not Modified
305 Use Proxy
307 Temporary Redirect
308 Permanent Redirect
4××客户端错误
400 Bad Request
401 Unauthorized
402 Payment Required
403 Forbidden
404 Not Found
405 Method Not Allowed
406 Not Acceptable
407 Proxy Authentication Required
408 Request Timeout
409 Conflict
410 Gone
411 Length Required
412 Precondition Failed
413 Payload Too Large
414 Request-URI Too Long
415 Unsupported Media Type
416 Requested Range Not Satisfiable
417 Expectation Failed
418 I’m a teapot
421 Misdirected Request
422 Unprocessable Entity
423 Locked
424 Failed Dependency
426 Upgrade Required
428 Precondition Required
429 Too Many Requests
431 Request Header Fields Too Large
444 Connection Closed Without Response
451 Unavailable For Legal Reasons
499 Client Closed Request
5××服务器错误
500 Internal Server Error
501 Not Implemented
502 Bad Gateway
503 Service Unavailable
504 Gateway Timeout
505 HTTP Version Not Supported
506 Variant Also Negotiates
507 Insufficient Storage
508 Loop Detected
510 Not Extended
511 Network Authentication Required
599 Network Connect Timeout Error
另一个潜在的治疗方法是使用PATCH。PATCH被定义为改变内部状态的东西，不局限于追加。
PATCH将通过允许您更新已经存在的项目来解决这个问题。参见:RFC 5789: PATCH
