API规范约定
?
为了高效开发,节约编写文档的成本,API服务使用Swagger来描述
一、API设计原则
- 控制API的粒度和数量
- 命名要遵循简单、可读、统一原则;
- 优先设计API,然后编码
二、URL设计【针对后端开发】
2.1 HTTP规范
动词目前暂时以下面两种 HTTP 方法,对应 CRUD 操作。
GET:读取(Read) POST:新建(Create,Update,Delete) PUT:更新(Update) PATCH:更新(Update),通常是部分更新 DELETE:删除(Delete)
2.2 命名规范
- 简洁
简洁 |
繁琐 |
captcha |
get-captcha-image |
info |
getUserInfo |
cars |
getAllCars |
- 可读
可读好 |
可读性差 |
delete |
delete-sysuser |
add |
addDetIstr |
update |
updateDetIstr |
get |
appGetByNO |
2.3 API臃肿
接口数量控制 |
反对不经过设计的API,导致API接口失控,接口过多,影响前端调试。 |
能合并的接口,尽量合并,不要写重复的接口 |
|
一个类的接口不要超过6个,如下图所示: |
转存失败完整状态码参看
2xx 状态码 200请求(或处理)成功 201请求(或处理)失败 4xx 状态码 400 Bad Request:请求参数不完整或不正确。 401 Unauthorized:未授权标识。 403 Forbidden:用户通过了身份验证,但是不具有访问资源所需的权限。 404 Not Found:所请求的资源不存在,或不可用。 405 Method Not Allowed:用户已经通过身份验证,但是所用的 HTTP 方法不在他的权限之内。 410 Gone:所请求的资源已从这个地址转移,不再可用。 415 Unsupported Media Type:客户端要求的返回格式不支持。比如,API 只能返回 JSON 格式,但是客户端要求返回 XML 格式。 422 Unprocessable Entity :客户端上传的附件无法处理,导致请求失败。 429 Too Many Requests:客户端的请求次数超过限额。 5xx 状态码 一般来说,API 不会向用户透露服务器的详细信息,所以只要两个状态码就够了。 500 Internal Server Error:客户端请求有效,服务器处理时发生了意外。 503 Service Unavailable:服务器无法处理请求,一般用于网站维护状态。
四、API返回格式规范
4.1API 的请求格式
|
4.2API 返回格式
响应一级目录包含三个字段如下所示:code,message,data
|
4.2.1 服务器异常格式
|
4.2.2 验证返回错误格式
|
4.2.3 列表格式
10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 |
|
4.2.4 权限格式
|
4.2.5 返回单个对象
10 11 |
|
4.2.6 树Tree格式
10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 |
|
4.2.7 返回DropDownList格式
10 11 12 13 14 15 16 |
|
5.3API 返回码
API 返回码如下:
API 返回码 |
含义 |
200 |
请求成功 |
40000 |
验证错误 |
500 |
服务器端错误 |
400 |
资源找不到 |
5.4内部服务调用接口
10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 |
|
?