36

重用这样的 RFC HTTP 状态代码是否被认为是一种好的做法，还是我们应该制作新的代码来精确映射到我们的特定错误原因？

我们正在围绕几个遗留应用程序设计一个 Web 服务 API。

除了响应正文中的 JSON/XML 数据结构外，我们的目标是返回对 Web 缓存和开发人员有意义的 HTTP 状态代码。

但是如何将不同类别的错误映射到适当的 HTTP 状态代码上呢？团队中的每个人都同意以下几点：

如果 1234 不存在，则GET /package/1234返回404 Not Found

GET /package/1234/next_checkpoint返回400 Bad Request如果“next_checkpoint”和1234 是有效的请求但 next_checkpont 这里没有意义......

等等......但是，在某些情况下，事情需要比“400”更具体 - 例如：

POST /dispatch/?for_package=1234返回412 Precondition Failed如果 /dispatch 和包 1234 都存在，但 1234 还没有准备好发送。

（编辑：HTTP/1.1中的状态代码和 WebDAV ext 中的状态代码。）

4

5 回答 5

25

RESTful 使用 HTTP 意味着您必须保持 API 统一。这意味着您无法添加特定于域的方法（ala GET_STOCK_QUOTE），但这也意味着您无法添加特定于域的错误代码（ala 499 Product Out Of Stock）。

事实上，HTTP 客户端错误代码是一个很好的设计检查，因为如果您正确设计资源语义，HTTP 错误代码含义将正确表达任何错误。如果你觉得你需要额外的错误代码，你的资源设计很可能是错误的。

简

于 2010-03-04T17:18:44.320 回答
19

422 Unprocessable Entity 对于这样的场景是一个有用的错误代码。当域规则无效时，请参阅此问题what http response code for rest service on put 方法 以获取更多信息。

于 2010-03-04T21:50:53.183 回答
5

GET /package/1234/next_checkpoint 返回 400 Bad Request 如果“next_checkpoint”和 1234 是有效的请求但 next_checkpont 这里没有意义......

这是考虑该 URI 的错误方式。

URI 是不透明的，因此从客户端的角度来看，观察它的一部分是“有效的”而其他部分不是没有任何意义。因此，您应该“只”向客户端返回 404，因为资源“package/1234/next_checkpoint”不存在。

于 2010-03-05T09:04:27.600 回答
4

当客户端出错时，您应该使用与您的请求最匹配的 4xx 系列响应，但请注意不要使用针对特定标头或条件的响应。我倾向于返回人类可读的状态消息和纯文本版本的错误作为响应正文或结构化错误消息，具体取决于应用程序上下文。

更新：在进一步阅读 RFC 后，“procondition failed”是指条件标头，例如“if-none-match”。我会为此给出一条一般的 400 消息。

于 2010-03-04T15:57:13.097 回答
0

实际上，您根本不应该这样做。您的使用404 Not Found是正确的，但400 Bad Request使用不当。A400 Bad Request根据 RFC 仅在 HTTP 协议格式错误时使用。在您的情况下，请求在语法上是正确的，这只是一个意外的参数。您应该返回 a500 Server Error然后在 REST 结果中包含错误代码。

于 2010-03-04T15:48:52.020 回答