前言
最近我司要制定开发规范。在讨论接口返回的时候，后端的同事询问我们前端，错误信息的返回，前端有什么意见？
所以做了一些调研给到后端的同事做参考。
错误信息返回
在使用API时无可避免地会因为各种情况而导致接口返回错误的信息。比如指定的query参数错误，又或者method不支持等，这些情况都会返回相关的错误信息。另外服务器不稳定或者停止运行了，也必须将错误信息返回。
显然，当错误发生的时候，只是笼统地返回“发生了错误”是不行的。如果前端不了解发生了什么错误，也就不知道该怎么去调试，怎么去修复这个bug。所以说，必须向前端返回尽可能多的信息，以便前端找到出错的地方解决问题。
通过HTTP状态码表示出错信息
首先必须选择合适的HTTP状态码，之前我司的后端API没有遵循这个规则。例如API无论如何访问，都会返回200状态码，只在返回消息体中的描述是否发生错误。
HTTP/1.1 200 OK
Content-Type: application/json
{
"error": {
"code": 2002,
"message": "Invalid parameter"
}
}虽然这么处理前端也能理解API的错误信息，但由于HTTP协议已经完整地定义了各个状态码所表示的含义，所以返回恰当的状态码才能提高前端正确识别错误的可能性。
如果出错了，仍然返回200状态码，有可能导致前端的处理发生混乱，这种情况要一定要禁止。特别是通用的API，基本上都是先看状态码再决定下一步的处理，如果没有返回正确的状态码，就会导致前端无法执行适当的方法去处理，从而引发各种不必要的问题。而且这种做法没有尽可能地运用HTTP协议，也给前端编写错误处理增加了难度。
- 状态码分类
| 状态码 | 含义 |
|---|---|
| 1xx | 消息 |
| 2xx | 成功 |
| 3xx | 重定向 |
| 4xx | 前端原因引起的错误 |
| 5xx |
下面主要来了解一下4xx和5xx的错误码：
4xx-前端发生了错误
4xx的状态码主要是用于描述因前端请求的问题而引发的错误，也就是说服务器端不存在出错问题，但服务器端无法理解前端的请求，或者能理解但无法处理的请求。这一类的错误，统一使用4xx错误码。
| 状态码 | 名称 | 说明 |
|---|---|---|
| 400 | Bad Request | 表示其他错误，就是4xx都无法描述的前端发生的错误 |
| 401 | Authentication | 表示认证类型的错误 |
| 403 | Authorization | 表示授权的错误（认证和授权的区别在于：认证表示“识别前来访问的是谁”，而授权则是“赋予特定用户执行特定操作的权限”） |
| 404 | Not Found | 表示访问的数据不存在 |
| 405 | Method Not Allowd | 表示可以访问接口，但是使用的HTTP方法不允许 |
| 406 | Not Acceptable | 表示API不支持前端指定的数据格式 |
| 408 | Request Timeout | 表示前端发送的请求到服务器所需的时间太长 |
| 409 | Confilct | 表示资源发生了冲突，比如使用已被注册邮箱地址注册时，就引起冲突 |
| 410 | Gone | 表示访问的资源不存在。不单表示资源不存在，还进一步告知该资源该资源曾经存在但目前已消失 |
| 413 | Request Entity Too Large | 表示请求的消息体过长而引发的错误 |
| 414 | Request-URI Too Large | 表示请求的首部过长而引发的错误 |
| 415 | Unsupported Media Type | 表示服务器端不支持客户端请求首部Content-Type里指定的数据格式 |
| 416 | Range Not Satisfiable | 表示无法提供Range请求中的指定的那段包体 |
| 417 | Expectation Failed | 表示对于Expect请求头部期待的情况无法满足时的响应码 |
| 421 | Misdirected Request | 表示服务器认为这个请求不该发给它，因为它没能力处理 |
| 426 | Upgrade Required | 表示服务器拒绝基于当前HTTP协议提供服务，通过Upgrade头部告知客户端必须升级协议才能继续处理 |
| 428 | Precondition Required | 表示用户请求中缺失了条件类头部，例如If-Match |
| 429 | Too Many Requests | 表示客户端发送请求的速率过快 |
| 431 | Request Header Fields Too Large | 表示请求的HEADER头部大小超出限制 |
| 451 | Unavailable For Legal Reasons | 表示由于法律原因不可访问 |
5xx-服务器端发生错误
5xx状态码表示错误由服务器端的问题引发的。
| 状态码 | 名称 | 说明 |
|---|---|---|
| 500 | Internal Server Error | 表示服务器内部错误，且不属于以下错误类型 |
| 501 | Not Implemented | 表示服务器不支持实现请求所需要的功能 |
| 502 | Bad Gateway | 代理服务器无法获取到合法资源 |
| 503 | Service Unavailable | 服务器资源尚未准备好处理当前请求 |
| 504 | Gateway Timeout | 表示代理服务器无法及时的从上游获得响应 |
| 505 | HTTP Verson Not Supported | 表示请求使用的HTTP协议版本不支持 |
| 507 | Insufficient Storage | 表示服务器没有足够的空间处理请求 |
| 508 | Loop Detected | 表示访问资源时检测到循环 |
| 511 | Network Authentication Required | 表示代理服务器发现客户端需要进行身份验证才能获得网络访问权限 |
向前端返回详细的错误信息
当错误发生时，除了需要返回相应的状态码之外，还需要返回详情的错误信息。因为状态码只是通用的描述错误的类别，一般无法表示实际发生的具体错误信息。
比如说400状态码，只是知道前端请求发生了错误，至于如何去修改，仅凭这个是没有办法找到bug的。
通常来说：返回错误信息的方法有两种：
- 将信息放入
HTTP响应头 - 将信息通过
HTTP响应体返回
1、通过自定义头部，将详细的错误信息放入响应头中
X-ERROR-CODE: 2020
X-ERROR-MESSAGE: Bad authentication token
X-ERROR-INFO: http://api.example.com/v1/authentication2、将错误信息放入响应体中
{
"error": {
"code": 2020,
"message": "Bad authentication token",
"info": "http://api.example.com/v1/authentication"
}
}从前端的角度来考虑，通过响应体返回会更加容易处理。
这里的错误代码的命名方式，按照后端自己的要求编写即可。
通常情况下，会要求接口的错误信息越详细越好，但这也不是一定的，也会有特殊情况。
一般而言，前端会将后端接口的错误信息原封不动的显示出来，因为前端很难去判断是否有涉密信息或者让用户难堪的信息。比如说A用户屏蔽了B用户，当B用户想看A用户的详情时，如果正确的返回：“A用户已屏蔽B用户，无法获取”的话，会让双方都难堪。这时就需要返回模棱两可的信息。这个就需要后端开发们自己去领悟。
针对默认返回与API维护
某些接口在发生错误时会将HTML返回。特别是发生404、503等错误时，这种情况就比较常见。当发生这些错误时，用于构建API的Web服务器或者app框架会直接返回出错信息，默认情况下大都是HTML。
但虽说是发生了错误，前端依然在访问中，所以仍然期待服务器返回约定好的格式，比如JSON。尤其在通过Accept请求头部或扩展名等指定了接收格式时。当然可以让前端去检查Content_Type头部，进行相应的处理。但如果前端处理的不好或者没有处理，可能会导致app崩溃。
尤其是公共api，不能期望所有的使用者都严格遵循规范来处理好，这种api算不上了好的api。
关于API的维护，正常来说，要避免不得不停止API的发生。但特殊的时候也会不得不停止API进行维护工作，这种情况需要返回503状态码来告知前端当前API已经停止工作。另外，因为这种停止操作不是意外而是有计划进行的，所以要有API何时重启的时间信息，将其发送给前端。
不仅要预备好用于定期维护的状态码和出错信息的返回，还要使用Retry-After头部来告诉前端维护结束的时间。从SEO的角度来看，这个方式对普通的web站点的维护也同样适用，也是Google推荐的方法。
Retry-After的值可以是某个具体的日期或从当前时刻算起至可正常访问为止所需的秒数。
503 Service Temporarily Unavailable
Retry-After: Mon, 9 Sep 2020 20:00:00 GMT 从前端实现的角度来看，在返回503错误时，是期待前端能识别出API地方Retry-After值指定的时间等待，然后在API重启的时候再次访问。
虽然这些处理都取决于前端的具体实现，后端无法对此进行控制，但依然要尽可能地返回详细的信息，方便前端处理并提升用户体验。
总结
主要是三个痛点：
- 必须选择合适的
HTTP状态码 - 向前端返回详细的错误信息
- 针对默认返回与
API维护