状态码是服务器向客户端反馈请求处理结果的重要方式
表示请求已被接收,需要继续处理。不过在实际的 RESTful API 开发中,1xx 状态码使用得相对较少。
客户端在发送包含 `Expect: 100-continue` 请求头的请求时,服务器如果愿意接受后续的数据,就会返回此状态码,告知客户端可以继续发送请求的其余部分。
当客户端通过请求头(如 `Upgrade`)要求切换协议时,若服务器同意切换,就会返回该状态码,比如从 HTTP 切换到 WebSocket。
表示请求已成功被服务器接收、理解并处理。
这是最常见的成功状态码,表明请求已成功处理,响应包含请求所需要的信息。比如客户端请求获取用户列表,服务器正常返回用户列表数据时就使用此状态码。
用于表示请求已经成功,并在服务器上创建了一个新的资源。通常在 POST 请求创建新资源后返回,响应中可能包含指向新创建资源的 URL。例如,客户端向服务器发送一个创建新用户的请求,服务器成功创建用户后返回 201 状态码。
表示请求已经被接受进行处理,但处理尚未完成。这通常用于异步处理的场景,服务器会返回一个状态信息,告知客户端稍后可以通过特定的方式查询处理结果。
请求已经成功处理,但响应中不包含任何实体内容。常用于客户端发送 DELETE 请求成功删除资源,或者 PUT 请求成功更新资源但不需要返回更新后的数据时。
表示需要客户端采取进一步的操作才能完成请求,通常是重定向到另一个 URL。
表示请求的资源已经永久移动到了新的 URL,客户端今后应该使用新的 URL 进行请求。搜索引擎在遇到此状态码时,会更新索引信息。
请求的资源临时移动到了另一个 URL,客户端应该继续使用原 URL 进行后续请求。不过,浏览器在处理 302 状态码时,有时会将 POST 请求转换为 GET 请求,这可能会导致一些问题。
告知客户端应该使用另一个 URL 来获取请求的资源,通常用于 POST 请求后,服务器希望客户端通过 GET 请求访问新的资源。
当客户端发送一个带有缓存验证信息(如 `If-Modified-Since` 或 `If-None-Match`)的请求时,如果资源自上次请求后没有发生变化,服务器会返回此状态码,客户端可以使用本地缓存的资源。
表示客户端可能存在错误,导致请求无法被服务器处理。
请求无效,可能是由于请求格式错误、缺少必要的参数等原因导致。例如,客户端发送的 JSON 数据格式不正确时,服务器可以返回此状态码。
请求需要用户进行身份验证,但客户端没有提供有效的身份验证信息。客户端需要提供正确的用户名和密码等凭证后重新发起请求。
客户端已经通过身份验证,但没有权限访问请求的资源。这可能是因为用户角色权限不足,或者资源本身不允许该用户访问。
请求的资源不存在,可能是 URL 拼写错误或者资源已经被删除。这是一个非常常见的状态码,当用户访问一个不存在的页面时,服务器通常会返回 404。
客户端使用的 HTTP 请求方法(如 GET、POST 等)不被该资源支持。例如,某个资源只允许 POST 请求,但客户端发送了一个 GET 请求,服务器就会返回此状态码。
请求与服务器上的当前状态冲突。比如在创建资源时,资源的某个唯一标识已经存在,就会产生冲突,服务器返回 409 状态码。
表示服务器在处理请求时发生了错误,无法完成请求。
这是最常见的服务器错误状态码,表示服务器在处理请求时遇到了意外情况,无法完成请求。可能是服务器代码出现了 bug、数据库连接失败等原因导致。
服务器作为网关或代理,从上游服务器接收到无效的响应。例如,服务器在转发请求到另一个服务器时,另一个服务器返回了错误的响应,就会返回 502 状态码。
服务器目前无法处理请求,通常是由于服务器过载、维护或者临时故障等原因导致。服务器可以在响应中包含一个 `Retry-After` 头,告知客户端在多长时间后可以再次尝试请求。
服务器作为网关或代理,在等待上游服务器的响应时超时。这可能是由于上游服务器响应过慢或者网络问题导致。