该怎么选择http状态码?

create on in computer_base with 0 comment and 72 view

http状态码非常多,很多人知道200,304,404,500,但很少有人知道201,202,301,302,400,401,402,501,502…

网上一搜,很多文章解释得非常齐全,也很专业,比如:

201: 请求已经被实现,而且有一个新的资源已经依据请求的需要而建立,且其 URI 已经随Location 头信息返回。假如需要的资源无法及时建立的话,应当返回 ‘202 Accepted’。

301: 被请求的资源已永久移动到新位置,并且将来任何对此资源的引用都应该使用本响应返回的若干个 URI 之一。如果可能,拥有链接编辑功能的客户端应当自动把请求的地址修改为从服务器反馈回来的地址。除非额外指定,否则这个响应也是可缓存的。新的永久性的 URI 应当在响应的 Location 域中返回。除非这是一个 HEAD 请求,否则响应的实体中应当包含指向新的 URI 的超链接及简短说明。如果这不是一个 GET 或者 HEAD 请求,因此浏览器禁止自动进行重定向,除非得到用户的确认,因为请求的条件可能因此发生变化。注意:对于某些使用 HTTP/1.0 协议的浏览器,当它们发送的 POST 请求得到了一个301响应的话,接下来的重定向请求将会变成 GET 方式。

好的,我看懂了(脑子:不,你不懂)。

状态码得用处

可能很多开发者一直有个疑问,为啥要整那么多状态码呢?别跟我说什么状态码,老夫只会200, 404,500,要么成功,要么失败!

当然,这种想法是不成熟的,因为从客户端请求到服务端响应这一过程,会存在着非常多的因素状况,比如资源缓存,请求错误,服务端错误,请求转移等等,我们可根据http的状态,去快速定位问题所在,以及根据状态做一些其它处理。这里给出几个具体原因:

  1. 客户端会处理(或者可以方便地被扩展以便处理)具有特定行为的不同状态码

    • 相比于 302 Found301 Moved Permanently 在 Google 等搜索引擎上有更好的 SEO 效果。
    • 301 Moved Permanently 能够被缓存,而 429 Too Many Requests 不被缓存等等。 有的客户端库可以处理 429 Too Many Request,将请求回退并一天之后再次尝试请求。 有的客户端可以用同样的方式处理 503 Service Unavilable
  2. 即使对现代需求不能完全满足,许多状态码依然代表着值得处理的特定响应

    • 那些本该返回 405 Method Not Allowed 却返回 404 的 API 让我疯狂地想,“究竟我是敲错了 URL 还是用错误的 HTTP method 请求了服务?”
    • 我能告诉你如果我们返回 502 Bad Gateway(上游服务问题)而不是返回让人困惑的 500 Internal Server Error,那么我们则能节省许多调试的时间。
  3. 在广泛被使用的 API 中建立一个约定,以返回约定的状态码,例如 201 Created429 Too Many Requests 以及 503 Service Unavialable。如果你遵循这个约定,用户将能更方便地使用你的网站/API并且解决任何他们可能遇到的问题。

怎么选择状态码?

令人遗憾的是,我们似乎在状态码上花费了太多的时间,因为状态码无法直观的体现出它的含义,很多开发者在状态码上花了太多时间去记忆,最后除了200,400,500,其它的还是忘得一干二净。
通常情况下,开发者需要大量的接触web中的各种状况,然后根据这些状况去选择正确的状态码,才能在我们的脑海中留下深刻的印象。

要理解状态码,最好的办法不是从状态码去看解释,而是根据实际情况,去选用状态码。

t01fcb848858d6f4e79.png

2xx/3xx状态码

t011cad6f61ee78675d.png

4xx状态码

t01e7b981390190e781.png

5xx状态码

最后,去研究http标准 RFC 7231

😁😂😃😄😅😆😇😈😉😐😑😒😓😔😕😖😗😘😙😠😡😢😣😤😥😦😧😨😩😰😱😲😳😴😵😶😷😸😹🙀🙁🙂🙃🙄🙅🙆🙇🙈
🙂