编者按：

不管你是否为软件开发人员，只要你跟互联网打交道，就不可避免的或明或暗的涉及到这些请求-响应关联的交互状态码。不管你是否为软件工程师，当浏览网页时出现了这样类似的状态码时，你基本都可以理解发生了什么，以便及时采取相应的应对之策。

本文主要对梳理出的HTTP以及REST状态码，做了简要归类和解释，以便你在遇到或设计时采用合理的具体处理。若有遗漏或错讹，还请指正补充。

内容分两部分内容，即HTTP状态码大全以及Rest状态码。

1、HTTP状态码

HTTP 定义了这些标准状态代码，可用于传达客户端请求的结果。状态码分为五类。

• 1xx：信息性——传达传输协议级信息。
• 2xx：成功——表示客户端的请求被成功接受。
• 3xx：重定向——表示客户端必须采取一些额外的行动才能完成他们的请求。
• 4xx：客户端错误——这类错误状态代码将矛头指向客户端。
• 5xx：服务器错误——服务器对这些错误状态代码负责。

具体一览表如下：

2、REST 特定的 HTTP 状态码

REST API 使用 HTTP 响应消息的Status-Line部分来通知客户端其请求的总体结果。 RFC 2616 定义了 Status-Line 语法，如下所示：

Status-Line = HTTP-Version SP Status-Code SP Reason-Phrase CRLF

由于微服务的盛行，作为互联网工程师，了解这些状态码，还是非常有必要的。下面介绍一下REST 服务中常用的状态码。

1） 200(OK)

此状态吗表明 REST API 成功地执行了客户端请求的任何操作，并且 2xx 系列中没有比200更具体的代码是合适的了。

与 204 状态代码不同，200 响应应包含响应正文。响应返回的信息取决于请求中使用的方法，例如：

• GET 在响应中发送与请求的资源对应的实体；
• HEAD 请求资源对应的实体标头字段在响应中发送，不带任何消息体；
• POST 描述或包含操作结果的实体；
• TRACE 包含终端服务器收到的请求消息的实体。

2） 201（Created）

每当在集合中创建资源时，REST API 都会使用 201 状态代码进行响应。有时，由于某些控制器操作而创建了新资源，在这种情况下，201 也是合适的响应。

新创建的资源可以被响应实体中返回的 URI 引用，资源的最具体的 URI 由 Location 头字段给出。

源服务器必须在返回 201 状态码之前创建资源。如果无法立即执行该操作，则服务器应该使用 202（已接受）响应来响应。

3） 202（Accepted）

202 响应通常用于需要很长时间才能处理的操作。表示请求已被接受处理，但处理尚未完成。该请求最终可能会或可能不会被执行，甚至可能在处理发生时被禁止。

其目的是允许服务器接受对其他进程的请求（可能是面向批处理的进程，每天只运行一次），而不需要用户代理与服务器的连接持续到进程完成。

与此响应一起返回的实体应该包括请求当前状态的指示和指向状态监视器（作业队列位置）的指针或用户可以期望何时完成请求的一些估计。

4） 204（No Content）

当 REST API 拒绝发回响应消息正文中的任何状态消息或表示时，通常会发送 204 状态代码以响应 PUT、POST 或 DELETE 请求。

API 还可以连同 GET 请求一起发送 204，以指示所请求的资源存在，但没有状态表示可包含在正文中。

如果客户端是一个用户代理，它不应该改变导致发送请求的文档视图。此响应主要用于允许操作的输入，而不会导致对用户代理的活动文档视图的更改。但是，任何新的或更新的元信息都应该应用于当前用户代理动态视图中的文档。

204 响应不能包含消息体，因此总是由标头（header）字段之后的第一个空行终止。

5） 301(Moved Permanently)

301 状态码表示 REST API 的资源模型已被大幅重新设计，并且已为客户端请求的资源分配了一个新的永久 URI。 REST API 应该在响应的 Location 标头中指定新的 URI，并且所有未来的请求都应该被定向到给定的 URI。

你几乎不会在 API 中使用此响应代码，因为你始终可以在保留旧 API 的同时使用新 API 的 API 版本控制。

6） 302（Found）

HTTP 响应状态码 302 Found 是执行 URL 重定向的常用方法。带有此状态代码的 HTTP 响应将在 Location 标头字段中另外提供一个 URL。带有此代码的响应邀请用户代理（例如，Web 浏览器）进行第二次响应。否则，就请求在location字段中指定的新 URL。

许多 Web 浏览器以违反此标准的方式实现此代码，将新请求的请求类型更改为 GET，而不管原始请求中使用的类型（例如 POST）。 RFC 1945 和 RFC 2068 指定不允许客户端更改重定向请求的方法。状态码 303 和 307 已被添加给服务器，以用于明确期望客户端做出何种反应。

7） 303（See Other）

303 响应表示控制器资源已完成其工作，但它不会发送可能不需要的响应正文，而是向客户端发送响应资源的 URI。响应可以是临时状态消息的 URI，也可以是一些已经存在的、更永久的资源的 URI。

一般来说，303 状态码允许 REST API 发送对资源的引用，而无需强制客户端下载其状态。相反，客户端可以向 Location 标头的值发送 GET 请求。

303 响应不能被缓存，但对第二个（重定向）请求的响应可能是可缓存的。

8） 304（Not Modified）

此状态码类似于 204（“No Content”），响应正文必须为空。关键区别在于，204 用于正文中没有要发送的内容，而 304 用于自请求标头 If-Modified-Since 或 If-None-Match 指定的版本以来没有修改资源时使用。

在这种情况下，不需要重新传输资源，因为客户端仍然有一个先前下载的副本。

使用它可以节省服务器和客户端的带宽和重新处理，因为与服务器重新处理的整个页面相比，只需发送和接收标头数据，然后利用服务器和客户端间更多带宽再次发送.

9） 307 (Temporary Redirect)

307 响应表明 REST API 不会处理客户端的请求。相反，客户端应该将请求重新提交到响应消息的 Location 标头指定的 URI。但是，未来的请求仍应使用原始 URI。

REST API 可以使用此状态代码将临时 URI 分配给客户端请求的资源。例如，307 响应可用于将客户端请求转移到另一台主机。

临时 URI 应该由响应中的 Location 字段给出。除非请求方法是 HEAD，否则响应的实体应该包含一个简短的超文本注释，其中包含指向新 URI 的超链接。如果收到 307 状态代码以响应 GET 或 HEAD 以外的请求，则用户代理不得自动重定向请求，除非用户可以确认，因为这可能会改变发出请求的条件。

10） 400(Bad Request)

400 是一般客户端错误状态，在没有其他 4xx 错误代码适用时使用。错误可能为格式错误的请求语法、无效的请求消息参数或欺骗性请求路由等。

客户端不应该在没有修改变化的情况下重复请求。

11） 401(Unauthorized)

401 错误响应表明客户端试图在未提供适当授权的情况下对受保护的资源进行操作。它可能提供了错误的凭据或根本没有提供。响应必须包含一个 WWW-Authenticate 标头字段，该字段包含适用于所请求资源的质询。

客户端可以使用合适的授权标头字段重复请求。如果请求已包含授权凭证，则 401 响应表示已拒绝对这些凭证的授权。如果 401 响应包含与先前响应相同的质询，并且用户代理已经尝试了至少一次身份验证，则应该向用户呈现响应中给出的实体，因为该实体可能包含相关的诊断信息。

12） 403(Forbidden)

403 错误响应表明客户端的请求格式正确，但 REST API 拒绝接受它，即用户没有资源的必要权限。 403 响应不是客户端凭据不足，就是 401（“Unauthorized”）。

身份验证将无济于事，并且不应重复请求。与 401 Unauthorized 响应不同，身份验证不会产生任何影响。

13） 404（Not Found）

404 错误状态代码表示 REST API 无法将客户端的 URI 映射到资源，但将来可能可用。客户的后续请求是允许的。

没有说明这种情况是暂时的还是永久性的。如果服务器通过一些内部可配置的机制知道旧资源永久不可用并且没有转发地址，则应该使用 410 (Gone) 状态代码。当服务器不希望确切地揭示请求被拒绝的原因或没有其他响应适用时，通常使用此状态代码。

14） 405（Method Not Allowed）

API 以 405 错误响应，表明客户端尝试使用资源不允许的 HTTP 方法。例如，只读资源只能支持 GET 和 HEAD，而控制器资源可能允许 GET 和 POST，但不支持 PUT 或 DELETE。

405 响应必须包含 Allow 标头，其中列出了资源支持的 HTTP 方法。例如：

Allow: GET, POST

15） 406(Not Acceptable)

406 错误响应表明 API 无法生成任何客户端的首选媒体类型，如 Accept 请求标头所示。例如，如果 API 只愿意将数据格式化为 application/json，则客户端对格式为 application/xml 的数据的请求将收到 406 响应。

如果响应可能不可接受，用户代理应该暂时停止接收更多数据并询问用户以决定进一步的操作。

16） 412(Precondition Failed)

412 错误响应表明客户端在其请求标头中指定了一个或多个先决条件，有效地告诉 REST API 只有在满足某些条件时才执行其请求。 412 响应表示不满足这些条件，因此 API 不执行请求，而是发送此状态代码。

17） 415(Unsupported Media Type)

415 错误响应表明 API 无法处理客户端提供的媒体类型，如 Content-Type 请求标头所示。例如，如果 API 只愿意处理格式为 application/json 的数据，则包含格式为 application/xml 的数据的客户端请求将收到 415 响应。

例如客户端上传图片为image/svg+xml，但服务器要求图片使用不同的格式。

18） 500(Internal Server Error)

500 是通用 REST API 错误响应。每当执行一些引发异常的请求处理程序代码时，大多数 Web 框架都会自动使用此响应状态代码进行响应。

500 错误绝不是客户端的错，因此，客户端重试触发此响应的同一请求并希望得到不同的响应是合理的。

这个API 响应是通用错误消息，在遇到意外情况且没有更具体的消息适合时给出。

19） 501（(Not Implemented)

服务器要么无法识别请求方法，要么无法完成请求。通常，这意味着未来的可用性（例如，Web 服务 API 的新功能）。

参考 ：

https://www.iana.org/assignments/http-status-codes/http-status-codes.xhtml

https://www.w3school.com.cn/

建议点赞、收藏，以备随时查阅和分享。