众所周知，HTTP响应中都会携带一个状态码。对于许多开发者来说，他们常用的状态码仅限于200、400、404和500等。而对于其他众多状态码，它们应该用在哪些场景中，何时应该使用哪些状态码，这些问题值得我们深入思考。即使在像这样的公司，其聪明的开发者构建的API也可能只返回200状态码。
为了深入理解HTTP状态码的适用场景以及它们的重要性，Michael Kropat撰写了一篇文章进行解析。
实际上，返回HTTP状态码是最简单不过的操作了。页面成功渲染就返回200；页面不存在就返回404；需要重定向到另一个页面就使用302或者301。
虽然这些操作看似简单，但如果有人告诉你，你的操作方式并不符合RESTful风格，那你可能需要警觉了。你是否考虑了新资源是否返回了RFC兼容的状态码？是200、204 No Content、202 Accepted，还是201 Created？
值得注意的是，官方的HTTP/1.1指南（RFC）是在1997年发布的，那时的我们还在使用Netscape Navigator和33.6kbps的调制解调器上网冲浪。尽管时代在变迁，但这些宝贵的建议仍然具有指导意义。我们需要深入理解它们。
如果有可视化的决策树，或许可以帮助我们快速识别与情况吻合的状态码，从而忽略不相关的选项。在这里我们可以参考文章中的某个图表。
该图表虽然看起来简单明了，但我发现很多人会陷入其中，纠结于“这种情况应该使用503 Service Unavailable还是404 Not Found呢？”等问题。如果你在不同的响应类别中思考具体的状态码，那可能说明你的做法存在问题。让我们再次看看上面提到的图表。
在继续之前我要强调几点：
1. 不必完全听从我的意见，请直接查阅RFC 7231和以获取更准确的信息。
2. 我所面向的读者是那些创建网站或使用REST API的开发者。
3. 我将响应码大致划分为三大类。
最后要说的是，虽然许多聪明的开发者在构建API时可能只返回200状态码，但状态码确实非常重要。现有的状态码对于现代网站/API来说有些过于宽泛，因此如果响应能包含更多细节信息，如哪些字段验证失败以及失败的原因，这将使客户端以更有意义的方式处理响应。那么，为什么不多花些时间研究那些“不太常用”的HTTP状态码呢？
关于为何使用具体的状态码非常重要，人们常提到的理由是HTTP是一个分层系统，客户端和服务器之间可能存在代理、缓存或其他HTTP库。如果响应码有意义，那么这些组件将更好地协同工作。即使未来都使用HTTPS并禁用所有代理和缓存节点，我仍然认为状态码非常重要。以下是我认为状态码至关重要的三个原因：
1. 客户端可以根据不同的状态码采取不同的行为，或者可以轻松扩展以应对。例如，301 Moved Permanently和302 Found对于Google和其他搜索引擎以及SEO有重要意义。客户端库可以通过延迟后重试来处理429 Too Many Requests或503 Service Unavailable等状态码。
2. 许多状态码所描述的情况可以通过特殊的响应进行处理。例如，当API返回404而不是405 Method Not Allowed时，可能会让用户困惑是输错了URL还是使用了错误的HTTP方法。正确区分502 Bad Gateway和500 Internal Server Error可以节省大量的调试时间。
3. 不容忽视的是，目前许多流行的APIs已经建立了一些约定，例如返回201 Created、429 Too Many Requests或503 Service Unavailable等。如果你的网站/API遵循这些约定，用户在使用时将更加轻松，遇到问题时也更容易解决。遵循这些约定的网站/API能够使用户体验更加顺畅，也更容易解决出现的问题。我强烈推荐大家阅读这篇文章，深入了解HTTP状态码的重要性和使用方法。
