umi 团队探索的接口格式与错误处理规范，还是很有借鉴意义的
HTTP Status Code
HTTP Status Codes
- 1XX - Informational
- 传输协议相关的信息，比如 101 Switching Protocals 表示请求协议切换
- 初始化请求的状态，比如 100 Continue 表示服务端收到请求头，在等待请求体
- 2XX - Success
- 200 OK
- 201 Created 表示请求被执行，新资源已经创建
- 202 Accepted 表示请求被接受，开始处理
- 3XX - Redirection
- 表示资源的状态
- 301 永久重定向
- 302 临时重定向
- 304 资源未更新
- 4XX - Client Error
- 400 Bad Request
- 404 Not Found
- 414 URI Too Long
- 429 Too many Requests
- 5XX – Server Error
- 500
- 502 Bad Gateway
- 503 Service Unavailable
Error Code
错误码通常意味着两种情况
- 请求或处理中出现了严重问题，API无法解析传递的数据
- API本身存在许多问题，即使是格式最好的请求也会失败
好的错误码必须传递 3 个信息
- HTTP Status Code
- Internal Reference ID：用于特定的错误，在一些情况，可以代替 HTTP Status Code，只要内部参考表包括 HTTP 状态码方案或类似的参考材料。
- readable messages
我觉得我们要分清楚状态码和错误码
- HTTP Status Code 只是描述了请求的状态，但该状态下的错误码可以多种多样
- Custom Error Code 具体错误下对应的错误码，这个肯定是很具体的，甚至可以帮助前后端工程师直接定位问题的。当然在某些情况下，HTTP Status Code 已经很具体了，比如 401 就是未登录，那么 Error Code 也可以直接和 HTTP Status Code 相等（因为这个已经是通识了）
- 不仅需要传达错误的类型，还需要传达错误发生的位置
- 错误码应该提供进一步的上下文，简单的 400 Bad Request，我们是看不出任何东西
所以我思考的结果是 HTTP Status Code + Custom Error Code 的方式。
文末资料中也提到，Twitter 和 Facebook 应该也是这样的方式。
参考方式
定义一套接口格式和错误处理的规范，当失败时统一提示错误，代码只需考虑成功即可，具体格式
- success：表示是否成功，为 false 时按照 showType 和 errorMessage 做统一的错误提示，同时抛出异常
- data：响应数据
- errorCode：自定义的错误编码
- errorMessage：提示给用户的错误信息
- showType：错误信息的提示方式
- silent：表示静默，不提示
- message.warn：警告类消息提示
- message.error：错误类消息提示
- notification：通知类型
- page：显示个错误页面，比如直接跳转到 /exception 页面
- traceId：唯一的请求 ID，方便后端进行错误排查
- host：当前访问的服务，也是为了后端进行错误排查
我个人十分想要的 showType 被公司后端同事吐槽，心塞塞