REST：被忽略的 POST 的正确 HTTP 响应代码
我们有一个 REST API，客户端可以定期向其 POST 和 PUT 数据。 当他们这样做时，有时他们会发布数据，这不会导致我们的系统发生任何变化。 POST 和 PUT 格式良好，但它们发送的数据与我们数据库中的数据相同。 发生这种情况时，我刚刚发现我们返回了 400 HTTP 状态。 不幸的是，这意味着“错误的请求”，如“由于语法错误，服务器无法理解请求”。
显然情况并非如此，但我被告知我们将使用它，因为没有其他合适的状态代码。 我们考虑过的选择：
- 304 Not Modified。 遗憾的是，这仅适用于 GET 请求。
- 204 无内容。 看起来很接近，但禁止实体主体。
其他选择似乎同样糟糕。 我们可能会选择 200 OK 并在返回的 XML 文档中包含相关信息，但这看起来不太“RESTish”。 REST 世界通常如何处理这个问题？
（已修复未修改响应代码。感谢 Mkoeller）
We have a REST API which clients routinely POST and PUT data to. When they do this, sometimes they POST data which results in no change on our system. The POSTs and PUTs are well-formed, but they data they're sending is identical to the data in our database. When this happens, I've just found out that we're returning a 400 HTTP status. Unfortunatly, this means "bad request" as in "request could not be understood by the server due to malformed syntax".
Clearly this is not the case, but I'm told that we're going to use this since there's no other appropriate status code. Choices we've considered:
- 304 Not Modified. This, regrettably, is only for GET requests.
- 204 No Content. Seems close, but forbids an entity-body.
Other choices seem equally bad. We might go with 200 OK and have the relevant information in the XML document we return, but this doesn't seem very "RESTish". How does the REST world generally handle this?
(Fixed Not Modified response code. Thanks Mkoeller)
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
我认为在这种情况下返回 200 OK 是完全可以的，数据已正确处理并且服务器做了它必须做的事情。 由于服务器正确处理了数据，因此它应该返回 OK 状态代码。 它在内部忽略它的事实是或应该是无关紧要的。
服务器对数据所做的操作不应该告诉客户端，而应该告诉客户端请求发生了什么（处理正常、发生错误等）。
如果出于某种奇怪的原因（顺便说一句，我想不出一个有效的原因），客户对此感兴趣，那么您可以回复告诉他们这一点。
I think it's perfectly fine to return a 200 OK in that case, the data was correctly processed and the server did what it had to. Because the server processed correctly the data, it should return an OK status code. The fact that it ignored it internally is or should be irrelevant.
What the server did to the data should not be told to the clients, they should be told what happened to the request (processed ok, error occurred, and the like).
And if, for some weird reason (I can't think a valid one, btw), it is of interest to the clients, you have the response to tell them so.
如果客户端在 PUT 之前能够知道服务器上内容的实体标记，则使用 If-Match 标头和 412 Precondition Failed 响应就可以满足您所描述的情况。
If the clients are able to know the entity tag for the content on the server before they PUT, then using If-Match headers and the 412 Precondition Failed response exists for exactly the situation you describe.
从客户端来看，无论服务器上的请求内容是否相同，服务器状态都是相同的，对吧？ 既然服务器随后准确地保存了发送的内容，为什么服务器要响应任何类型的错误状态呢？
另一方面，如果请求内容与服务器已知的内容相同，客户端为什么还要麻烦呢？ 它已成功传输到服务器，因此大部分工作已完成。 如果针对这种情况有不同的响应代码，客户预计会如何反应？
结论：您的请求内容等于现有内容的情况并非特例。 您应该使用相同的响应状态代码进行响应。 可能是 200、302 或 303。
From client view the server status is the same if the request content was the same on the server or not, right? Since the server afterwards holds excactly the content that was sent, why should the server respond with any kind of error status?
On the other hand why should the client bother if the request content was the same as already known to the server? It was successfully transfered to the server so the bulk of work is done. How is a client expected to react if there was a different response code for this situation?
Conclusion: Your situation of a request content equaling the existing content is no special case. You should respond with the same response status code. That might be 200, 302 or 303.