RESTFull API 错误定义

1.编写目的

最近和前端编码人员，就错误格式定义存在异议。同事坚持只使用HTTP状态码，个人觉得HTTP状态码并不能囊括全部的出错信息，需要另外定义和业务息息相关的业务错误码，所以google了一下其他开发者的见解，记下笔记。

 

2.借鉴系统错误格式

Github (use http status)

{ "message": "Validation Failed", "errors": [ { "resource": "Issue", "field": "title", "code": "missing_field" } ] }

Google (use http status)

{ "error": { "errors": [ { "domain": "global", "reason": "insufficientFilePermissions", "message": "The user does not have sufficient permissions for file {fileId}." } ], "code": 403, "message": "The user does not have sufficient permissions for file {fileId}." } }

Twilio (use http status)

{ "code": 21211, "message": "The 'To' number 5551234567 is not a valid phone number.", "more_info": "https://www.twilio.com/docs/errors/21211", "status": 400 }

 

3. 分析总结

|-- 不应该完全摒弃HTTP状态码，

并不能确定当前组件之后会有哪些系统来调用它，对于一个比较大的工程来说，可能会用到很多第三方组件，这些组件只会按照业界通行的标准来设计。 为软件的通用性考虑，RESTfull需要携带正确的HTTP状态码，不可逶迤。

|-- 需要携带业务相关的错误码

框架不应该与业务耦合，个人觉得HTTP状态码应由框架维护，业务部分的状态码应与其分开。

错误分类

|-- 全局错误

由web框架捕获， 与系统业务分离

400: 请求语法错误，服务器不能理解

401: 未授权错误

403: 无访问权限

404: 找不到资源

408: 请求超时

 

500: 服务器内部错误

 

|-- 业务错误

10001： 账号不存在

10002： 密码错误

 

4. 结构示例

|-- 分两套管理是，httpcode 和 code 同时存在

httpccode: 201

response: {

code ： 0000，

message: "创建成功"，

detail: {}.

data: {},

}

 

httpccode: 201

response: {

code ： 10001，

message: "账号不存在"，

detail: { },

data: {},

}

 

httpccode: 401

response: {

code ： 10002，

message: "当前用户未授权"，

detail: {},

data: {},

}