6

什么是合适的响应代码和消息：

  1. 字段提交方式错误（URL 参数与正文）或缺少字段
  2. 字段获取无效值（字符串而不是数字，将来的时间戳）
  3. 某些字符，例如?, /URL 参数中的中断内容
  4. 实际失败：无效凭据，重复已经完成的操作

目前，我们全部使用400。

4

2 回答 2

6

您问题中的案例 1、2 和 3 本质上是请求中的语法错误

=> 400 错误请求

（RFC 2616 说：由于语法错误，服务器无法理解请求。）

至于案例4：

一个。无效证件

=> 401 未经授权

湾。重复已经完成的动作

=> 403 禁止

（RFC 说：服务器理解请求，但拒绝执行。授权无济于事，请求不应重复。）

但是，当尝试错误地修改内容 (PUT) 或访问已删除的资源时， 409 Conflict和410 Gone是有意义的。

这是RFC 2616 第 10 节。

于 2012-07-04T09:47:10.787 回答
3

阅读每个响应代码的 HTTP 规范，以获取有关在响应正文中返回的内容的一些信息。例如，4xx 表示“除了响应 HEAD 请求时，服务器应该包含一个表示，其中包含对错误情况的解释，以及它是暂时的还是永久的情况。”

要记住的主要一点是，HTTP 响应代码被设计为统一的，因此与促进互操作性有关，而不是满足单个应用程序的详细需求。使用响应正文而不是代码，以您希望客户理解的格式包含详细信息。

1 个字段以错误的方式提交（URL 参数与正文）或缺少字段

返回“404 未找到”。查询字符串参数是 URI 的一部分，用于标识资源。/foo/bar?a=1&b=2标识与 不同的资源foo/bar。如果资源不存在，则返回 404。代码中的相同逻辑用于处理相同路径的任何查询字符串参数并不重要：这些细节被有意隐藏在统一接口后面。有关更多详细信息，请参阅URI 规范。

2 个字段获得无效值（字符串而不是数字，未来的时间戳）

400 在这里是最好的，除非资源处于与用户可以合理地解决（然后重新提交请求）的请求相冲突的状态，在这种情况下返回 409。

3 一些字符，如 ?, / 破坏 URL 参数中的内容

如果这种破坏是由于您的服务器未正确处理查询字符串组件中的保留字符，则返回 500。如果客户端提交了格式错误的 Request-URI，则返回 400。如果 URI 标识了您的服务器未处理的资源，则返回 404。

4 实际失败：无效凭据，重复已经完成的操作

无效的凭据应导致“401 Unauthorized”。如果请求方法是幂等的（GET、HEAD、PUT、DELETE），重复已经完成的操作应该会导致 200 OK（或重定向等）。对于 POST，重复操作完全取决于操作的性质，实际上可能会返回任何状态代码。400/409 很常见，但许多此类资源只是再次执行操作，这通常是可取的。

于 2012-07-04T18:57:56.107 回答