HTTP/1.1规范（RFC2616）定义了许多状态码，可以由HTTP服务器返回以表示某些情况。其中一些代码可以被Web应用程序和框架利用。在经典和异步（XHR）响应中，哪些代码在实践中最有用，在什么情况下使用每个代码？应避免使用哪些代码，例如，应用程序是否应处理5xx代码范围？在返回REST Web服务的HTTP代码时，您的约定是什么？除了302之外，您是否曾经使用过其他重定向？
12个回答
13
我正在使用的（我可以快速使用
grep 'Status:'找到的）：
- 200 成功获取资源，但不影响它
- 201 当表单提交将重要内容放入数据库（论坛帖子、用户账户等）并创建新资源时发送
- 204 发送空主体，例如在DELETE之后
- 304 HTTP缓存。我发现这个非常难以做到正确，因为它必须考虑到用户更改显示设置等因素。我想到的最好的方法是使用用户首选项的哈希作为ETag。这并没有帮助，因为大多数浏览器在这里具有不可预测和不一致的行为...
- 400 用于提交错误的表单，未通过某些验证检查。
- 403 当某人在他们不应该去的地方时使用（尽管我尝试避免通过不显示用户不应访问的内容来实现这一点）。
- 404 除了正常的Web服务器之外，当URL包含无效的ID号码时，我也会使用这些。我想，在这种情况下，检查是否存在更高的有效ID并发送410可能是一个好主意...
- 429 当用户请求过于频繁时
- 500：我倾向于将这些放在catch{}块中，唯一的选择是放弃，以确保向浏览器发送有意义的内容。
我意识到我可以简单地让服务器对所有事情都发送“200”，但当用户看到（或导致）错误并且没有告诉您时，他们会避免很多痛苦。我已经有了显示访问被拒绝消息等功能，因此添加这些功能并不需要太多工作。
- user42092
3
谢谢，我一直在寻找这样实用的观点。你是否使用201而不是200有特定的原因，还是只是为了更好地遵守标准？ - Adam Byrtek
顺便说一句，我认为你检查更高的ID并发送410而不是404的想法对我来说似乎有些过度。 - Adam Byrtek
201状态码主要是为了完整性而存在的，虽然它确实有助于跟踪特定代码片段中的错误（例如，您可以查看访问日志并查看表单是否成功处理）。 - user42092
13
418: 我是茶壶
来自http://www.ietf.org/rfc/rfc2324.txt 超文本咖啡壶控制协议 (HTCPCP/1.0)
- Rich Bradshaw
1
1我最喜欢的调试状态码 :) - Mathieu Rodic
7
不要忘记503 - 服务不可用。这对于网站停机时间非常重要，尤其是涉及搜索引擎的情况。
比如说，您需要将网站关闭几个小时进行维护或升级工作。通过将所有请求重定向到返回503代码的友好页面，它告诉蜘蛛“稍后再试”。
如果您只显示一个“暂时关闭”的页面，但仍然返回200 OK，则蜘蛛可能会索引您的错误页面，或者更糟的是，用这个“新”内容替换现有的索引。
这可能严重影响您的SEO排名，特别是如果您是一个大型、受欢迎的网站。
比如说，您需要将网站关闭几个小时进行维护或升级工作。通过将所有请求重定向到返回503代码的友好页面，它告诉蜘蛛“稍后再试”。
如果您只显示一个“暂时关闭”的页面，但仍然返回200 OK，则蜘蛛可能会索引您的错误页面，或者更糟的是，用这个“新”内容替换现有的索引。
这可能严重影响您的SEO排名，特别是如果您是一个大型、受欢迎的网站。
- Kevin
2
以下是我从经验中总结出来的最常见的响应代码：
1xx-2xx范围内的响应代码通常由底层Web服务器（如Apache、IIS）自动处理，因此您不需要担心这些代码。
301和302代码通常用于重定向，304代码在客户端或代理已包含数据的有效副本且不需要从服务器获取新版本时经常使用（有关其详细工作原理，请参见RFC）。
400代码通常用于指示客户端发送了错误或意外的数据，导致服务器出现问题。
403代码用于执行身份验证，这通常也由服务器配置自动处理。
404代码是页面未找到的错误代码。
500代码表示服务器中的错误条件并不一定是由客户端发送的数据引起的。例如，数据库连接失败、编程错误或其他未处理的异常。
502代码通常在您从Web服务器（如Apache）代理到后端的应用程序服务器（如Tomcat）时出现，如果无法连接到应用程序服务器，则会出现该代码。
对于异步调用（即AJAX / JSON响应），通常最安全的做法是始终返回200响应。即使在服务器处理请求时出现错误，最好也将错误包含在JSON对象中，并让客户端以这种方式处理它。原因是，并非所有Web浏览器都允许访问非200响应代码的响应正文。
1xx-2xx范围内的响应代码通常由底层Web服务器（如Apache、IIS）自动处理，因此您不需要担心这些代码。
301和302代码通常用于重定向，304代码在客户端或代理已包含数据的有效副本且不需要从服务器获取新版本时经常使用（有关其详细工作原理，请参见RFC）。
400代码通常用于指示客户端发送了错误或意外的数据，导致服务器出现问题。
403代码用于执行身份验证，这通常也由服务器配置自动处理。
404代码是页面未找到的错误代码。
500代码表示服务器中的错误条件并不一定是由客户端发送的数据引起的。例如，数据库连接失败、编程错误或其他未处理的异常。
502代码通常在您从Web服务器（如Apache）代理到后端的应用程序服务器（如Tomcat）时出现，如果无法连接到应用程序服务器，则会出现该代码。
对于异步调用（即AJAX / JSON响应），通常最安全的做法是始终返回200响应。即使在服务器处理请求时出现错误，最好也将错误包含在JSON对象中，并让客户端以这种方式处理它。原因是，并非所有Web浏览器都允许访问非200响应代码的响应正文。
- Marc Novakowski
2
当有人试图获取只能通过POST方式访问的URL时，我倾向于使用405 Method Not Allowed状态码。还有其他人也是这样做吗？
- Adam Byrtek
1
在Aida/Web框架中，我们只使用以下几种状态码：
- 200 OK
- 302 重定向
- 404 未找到
- 500 服务器内部错误
- Mivsek
1
我基本上根据需要使用它们。规范本身定义了每个代码及其应使用的情况。
在构建RESTful Web应用程序时，我不建议挑选状态码，并将自己限制在部分完整范围内。除非为特定的HTTP客户端构建Web应用程序 - 在这种情况下，您实际上并不是在构建Web应用程序，而是在为该特定客户端构建应用程序。
在我们公司中，我们有一些Flex客户端。它们无法正确处理200以外的状态码，因此我们让它们发送一个特殊参数来告诉我们的服务器始终发送200，即使这不是正确的响应。
- Avi Flax
1
我并不是指限制你自己，而是在典型Web应用程序的上下文中，只有某些状态码子集是有意义的。有些仅在涉及Web服务器或代理时有用，另一些则非常特定且在实践中很少使用。 - Adam Byrtek
0
对于用户数据错误（例如表单提交），我使用409而不是400。
关于409的规范提到了版本冲突，但它还提到修复问题的信息应该在响应中发送。这非常适合处理格式错误的电子邮件或密码错误的消息。
400只处理语法问题，对我来说，这听起来像是请求根本就没有意义，而不是未通过某些正则表达式。
- jhnstn
0
我曾经做过关于数字500的噩梦。
- mmarshall
2
好的，没有HTTP状态码666 :) - Adam Byrtek
更严肃地说，当您更改了某个东西的URL时，301（永久移动）非常有用。 - Matthew Marshall
网页内容由stack overflow 提供, 点击上面的可以查看英文原文，
原文链接
原文链接