HTTP接口报错详解与解决 200,500,403,408,404

前言：

仅做学习记录，侵删

背景

当后端编写接口时，经常需要对接口使用ApiFox或者PostMan进行测试，此时就会出现各种各样的报错，一般都会包括报错编码：200,400,401等。这个状态码一般是服务器所返回的包含http状态码的信息头（server header）用以响应请求。

程序员最想看到的：200-OK。

程序员不想看到的：500-Internal-Server-Error。

用户不想看到的：401-Unauthorized、403-Forbidden、408-Request-Time-out、404-not-found。

常见的Http状态码

HTTP状态码组成

一般情况下由HTTP 状态码由三个十进制数字组成，第一个十进制数字定义了状态码的类型。

HTTP状态码分类

一般情况下响应分为五类：

1. 信息响应(100–199)
2. 成功响应(200–299)
3. 重定向(300–399)
4. 客户端错误(400–499)
5. 服务器错误 (500–599)

分类	分类描述
1**	信息，服务器收到请求，需要请求者继续执行操作
2**	成功，操作被成功接收并处理
3**	重定向，需要进一步的操作以完成请求
4**	客户端错误，请求包含语法错误或无法完成请求
5**	服务器错误，服务器在处理请求的过程中发生了错误

HTTP状态码列表

📌备注： 如果你收到的响应不在此列表中，则它为非标准响应，可能是服务器软件的自定义响应。

信息响应(100–199)

状态码	状态码英文名称	中文描述
100	Continue	这个临时响应表明，迄今为止的所有内容都是可行的，客户端应该继续请求，如果已经完成，则忽略它。
101	Switching Protocols	切换协议。服务器根据客户端的请求切换协议。只能切换到更高级的协议，例如，切换到HTTP的新版本协议
102	Processing (WebDAV)	此代码表示服务器已收到并正在处理该请求，但当前没有响应可用。
103	Early Hints	此状态代码主要用于与 Link 链接头一起使用，以允许用户代理在服务器准备响应阶段时开始预加载 preloading 资源。

成功响应(200–299)

状态码	状态码英文名称	中文描述
200	OK	请求成功。一般用于GET与POST请求
201	Created	已创建。成功请求并创建了新的资源
202	Accepted	已接受。已经接受请求，但未处理完成
203	Non-Authoritative Information	非授权信息。请求成功。但返回的meta信息不在原始的服务器，而是一个副本
204	No Content	无内容。服务器成功处理，但未返回内容。在未更新网页的情况下，可确保浏览器继续显示当前文档
205	Reset Content	重置内容。服务器处理成功，用户终端（例如：浏览器）应重置文档视图。可通过此返回码清除浏览器的表单域
206	Partial Content	部分内容。服务器成功处理了部分GET请求
207	Multi-Status (WebDAV)	响应主体是一个带有 `multistatus` 根元素的 `text/xml` 或 `application/xml` HTTP 实体。XML 主体将列出所有单独的响应状态码。
208	Already Reported (WebDAV)	在 DAV 里面使用 `<dav:propstat>` 响应元素以避免重复枚举多个绑定的内部成员到同一个集合。
226	IM Used (HTTP Delta encoding)	服务器已经完成了对资源的`GET`请求，并且响应是对当前实例应用的一个或多个实例操作结果的表示。

重定向消息(300–399)

状态码	状态码英文名称	中文描述
300	Multiple Choices	多种选择。请求的资源可包括多个位置，相应可返回一个资源特征与地址的列表用于用户终端（例如：浏览器）选择
301	Moved Permanently	永久移动。请求的资源已被永久的移动到新URI，返回信息会包括新的URI，浏览器会自动定向到新URI。今后任何新的请求都应使用新的URI代替
302	Found	临时移动。与301类似。但资源只是临时被移动。客户端应继续使用原有URI
303	See Other	查看其它地址。与301类似。使用GET和POST请求查看
304	Not Modified	未修改。所请求的资源未修改，服务器返回此状态码时，不会返回任何资源。客户端通常会缓存访问过的资源，通过提供一个头信息指出客户端希望只返回在指定日期之后修改的资源
305	Use Proxy	使用代理。所请求的资源必须通过代理访问
306	Unused	已经被废弃的HTTP状态码
307	Temporary Redirect	临时重定向。与302类似。使用GET请求重定向
308	Permanent Redirect	这意味着资源现在永久位于由`Location:` HTTP Response 标头指定的另一个 URI。这与 `301 Moved Permanently` HTTP 响应代码具有相同的语义，但用户代理不能更改所使用的 HTTP 方法：如果在第一个请求中使用 `POST`，则必须在第二个请求中使用 `POST`。

客户端错误(400–499)

状态码	状态码英文名称	中文描述
400	Bad Request	客户端请求的语法错误，服务器无法理解
401	Unauthorized	请求要求用户的身份认证
402	Payment Required	保留，将来使用
403	Forbidden	服务器理解请求客户端的请求，但是拒绝执行此请求
404	Not Found	服务器无法根据客户端的请求找到资源（网页）。通过此代码，网站设计人员可设置"您所请求的资源无法找到"的个性页面
405	Method Not Allowed	客户端请求中的方法被禁止
406	Not Acceptable	服务器无法根据客户端请求的内容特性完成请求
407	Proxy Authentication Required	请求要求代理的身份认证，与401类似，但请求者应当使用代理进行授权
408	Request Time-out	服务器等待客户端发送的请求时间过长，超时
409	Conflict	服务器完成客户端的 PUT 请求时可能返回此代码，服务器处理请求时发生了冲突
410	Gone	客户端请求的资源已经不存在。410不同于404，如果资源以前有现在被永久删除了可使用410代码，网站设计人员可通过301代码指定资源的新位置
411	Length Required	服务器无法处理客户端发送的不带Content-Length的请求信息
412	Precondition Failed	客户端请求信息的先决条件错误
413	Request Entity Too Large	由于请求的实体过大，服务器无法处理，因此拒绝请求。为防止客户端的连续请求，服务器可能会关闭连接。如果只是服务器暂时无法处理，则会包含一个Retry-After的响应信息
414	Request-URI Too Large	请求的URI过长（URI通常为网址），服务器无法处理
415	Unsupported Media Type	服务器无法处理请求附带的媒体格式
416	Requested range not satisfiable	客户端请求的范围无效
417	Expectation Failed（预期失败）	服务器无法满足请求头中 Expect 字段指定的预期行为。
418	I'm a teapot	状态码 418 实际上是一个愚人节玩笑。它在 RFC 2324 中定义，该 RFC 是一个关于超文本咖啡壶控制协议（HTCPCP）的笑话文件。在这个笑话中，418 状态码是作为一个玩笑加入到 HTTP 协议中的。服务端拒绝用茶壶煮咖啡。笑话，典故来源茶壶冲泡咖啡
421	Misdirected Request	请求被定向到一个无法生成响应的服务器。如果连接被重复使用或选择了其他服务，就有可能出现这种情况。
422	Unprocessable Entity (WebDAV)	服务器理解请求实体的内容类型，并且请求实体的语法是正确的，但是服务器无法处理所包含的指令。
423	Locked (WebDAV)	暂定目标资源被锁定，即无法访问。其内容应包含一些 WebDAV XML 格式的信息。
424	Failed Dependency (WebDAV)	由于请求的操作依赖于另一个操作，且该操作失败，因此无法在资源上执行该方法。普通 web 服务器通常不会返回此状态代码。但其他一些协议，如 WebDAV 可以返回该状态代码。例如，在 WebDAV 中，如果发出了 `PROPPATCH` 请求，其中一条命令失败，那么其他命令也会自动以 `424 Failed Dependency` 的形式失败。
425	Too Early 实验性	代表服务器不愿意冒风险来处理该请求，原因是处理该请求可能会被“重放”，从而造成潜在的重放攻击。
426	Upgrade Required	服务器拒绝使用当前协议执行请求，但在客户端升级到其他协议后可能愿意这样做。服务端发送带有Upgrade 字段的 426 响应来表明它所需的协议（们）。
428	Precondition Required	源服务器要求请求是有条件的。此响应旨在防止'丢失更新'问题，即当第三方修改服务器上的状态时，客户端 `GET` 获取资源的状态，对其进行修改并将其 `PUT` 放回服务器，从而导致冲突。
429	Too Many Requests	用户在给定的时间内发送了太多请求（"限制请求速率"）
431	Request Header Fields Too Large	服务器不愿意处理请求，因为其头字段太大。在减小请求头字段的大小后，可以重新提交请求。
451	Unavailable For Legal Reasons	用户代理请求了无法合法提供的资源，例如政府审查的网页。

服务器错误 (500–599)

状态码	状态码英文名称	中文描述
500	Internal Server Error	服务器内部错误，无法完成请求
501	Not Implemented	服务器不支持请求的功能，无法完成请求
502	Bad Gateway	作为网关或者代理工作的服务器尝试执行请求时，从远程服务器接收到了一个无效的响应
503	Service Unavailable	由于超载或系统维护，服务器暂时的无法处理客户端的请求。延时的长度可包含在服务器的Retry-After头信息中
504	Gateway Time-out	充当网关或代理的服务器，未及时从远端服务器获取请求
505	HTTP Version not supported	服务器不支持请求的
506	Variant Also Negotiates	服务器存在内部配置错误：所选的变体资源被配置为参与透明内容协商本身，因此不是协商过程中的适当终点。
507	Insufficient Storage (WebDAV)	无法在资源上执行该方法，因为服务器无法存储成功完成请求所需的表示。
508	Loop Detected (WebDAV)	服务器在处理请求时检测到无限循环。
510	Not Extended	服务器需要对请求进行进一步扩展才能完成请求。
511	Network Authentication Required	指示客户端需要进行身份验证才能获得网络访问权限。

常见的HTTP状态码出错解决

HTTP 400 错误

🚫警告： 客户端不应该在未进行修改的情况下重复发送此请求。

说明

当状态码为400时，主要有两种形式：

1、bad request 意思是 "错误的请求"；
2、invalid hostname 意思是 "不存在的域名"。

由上述列表，400 Bad Request 是由于明显的客户端错误（例如，格式错误的请求语法，太大的大小，无效的请求消息或欺骗性路由请求），服务器不能或不会处理该请求。

原因

在 ajax 请求后台数据时比较常见。产生 HTTP 400 错误的原因有：

1、前端提交数据的字段名称或者是字段类型和后台的实体类不一致，导致无法封装；
2、前端提交的到后台的数据应该是 json 字符串类型，而前端没有将对象转化为字符串类型；

解决方案：

1、对照字段名称，类型保证一致性
2、使用 stringify 将前端传递的对象转化为字符串：

data: JSON.stringify(param);

常见情况

传参错误

传null值给一个非空字段

数据格式错误，比如传一个JSON格式的数据给String类型

404 NOT FOUND！

说明

404页面是网站必备的一个页面，它承载着用户体验与SEO优化的重任。如果站长没有设置404页面，会出现死链接，蜘蛛爬行这类网址时，不利于搜索引擎收录。

原因

404页面通常为用户访问了网站上不存在或已删除的页面，服务器返回的404错误。

404 Not Found 由来

据说在第三次科技革命之前，互联网的形态就是一个大型的中央数据库，这个数据库就设置在404房间里面。那时候所有的请求都是由人工手动完成的，如果在数据库中没有找到请求者所需要的文件，或者由于请求者写错了文件编号，用户就会得到一个返回信息：room 404 : file not found。后来互联网兴起后，人们也就习惯了用404作为服务器未找到文件的错误代码了。当然实际考证传说中的room 404是不存在的。

设置404页面的两大好处

引导用户不要关闭网站，增强用户体验。
防止网站出现死链接。

常见情况

请求的接口路径错误，比如实际接口路径为tblTeacher/getTeacherName，但却写成了tblTeacher/getTeacher

500 Internal Server Error

说明

在 HTTP 协议中，500 Internal Server Error 是表示服务器端错误的响应状态码，意味着所请求的服务器遇到意外的情况并阻止其执行请求。

这个错误代码是一个通用的“万能”响应代码。有时候，对于类似于 500 这样的错误，服务器管理员会更加详细地记录相关的请求信息来防止以后同样错误的出现。

一般情况下为代码逻辑错误，请检查编辑器后台服务日志。

原因

这种报错原因比较多，一般情况下都会有后台报错日志显示具体的报错原因和位置，可以根据后台所产生的具体报错原因去搜索对应的解决办法。一般情况下为代码逻辑错误，比如产生空指针异常等。

解决方案

检查服务器日志：查看服务器的日志文件，以获取更详细的错误信息。服务器日志通常记录了发生错误的原因和具体的错误消息。根据日志信息，尝试定位和解决问题。
检查服务器端代码：如果你有权限访问服务器端的代码，仔细检查服务器端的代码逻辑，确认没有错误或异常情况。确保代码没有bug，并且能够正确地处理请求。
检查服务器配置：检查服务器的配置文件，确保配置正确。可能是某个配置项的值不正确，导致服务器无法正常运行。根据服务器的类型和使用的软件，检查相关的配置文件，并进行必要的修改。
重启服务器：尝试重启服务器，以解决可能由于服务器进程或服务异常导致的问题。重启服务器可以清除临时的错误状态，并重新启动服务器进程。