API接口规范
在RESTful 规范的基础上,根据管理类型项目的开发经验,对API接口进行了定制化和规范化,以减少沟通成本,提高开发和维护效率。
除了对请求的方法和URL进行了规范,对请求的返回数据格式也进行了规范化。
查询
查询某个数据模型的全部数据列表
Method | GET | |
URL | http://{{server_url}}/api/v1.0/{url_prefix}/ | |
Payload | - | |
Return | 包含状态和数据列表/异常信息的json对象 | |
-成功 |
|
|
-失败 |
|
|
备注 |
请求失败有两种情况
|
条件查询
包含分页、搜索、排序等的条件查询
Method | POST | |
URL | http://{{server_url}}/api/v1.0/{url_prefix}/pss/ | |
Payload | 分页/搜索/排序等查询条件 | |
|
||
Return | 包含状态和数据列表/异常信息的json对象 | |
-成功 |
|
|
-失败 |
|
|
备注 | 采用POST的方式,以更好的组织请求条件数据 |
添加
添加数据
Method | POST | |
URL | http://{{ server_url}}/api/v1.0/{url_prefix}/ | |
Payload | 要添加的json数据对象 | |
|
||
Return | 包含状态和添加成功以后的模型数据/异常信息的json对象 | |
-成功 |
|
|
-失败 |
|
|
备注 |
删除
删除指定的数据
Method | DELETE | |
URL | http://{{ server_url}}/api/v1.0/{url_prefix}/[pk_value] | |
Payload | - | |
Return | 包含状态和删除成功以后的模型数据/异常信息的json对象 | |
-成功 |
|
|
-失败 |
|
|
备注 | 在URL中指定要删除的主键信息 |
修改
修改指定的数据,分为局部修改和全量替换
局部修改
只对传递的数据中指定的属性进行更新,数据中没有的属性保持不变
Method | PATCH | |
URL | http://{{ server_url}}/api/v1.0/{url_prefix}/ | |
Payload | 包含主键信息的要修改数据的json对象 | |
|
||
Return | 包含状态和修改成功以后的模型数据/异常信息的json对象 | |
-成功 |
|
|
-失败 |
|
|
备注 | 这里没有将主键放到URL中,主要是考虑到总会有Payload数据,所以将主键信息放到了Payload中,这是跟RESTful规范不同的地方,也可以完全按照RESTful规范,将主键放到URL中 |
全量替换
以替换的方式对数据进行替换,如果属性不存在则置空
Method | PUT | |
URL | http://{{ server_url}}/api/v1.0/{url_prefix}/ | |
Payload | 包含主键信息的要修改的全量数据json对象 | |
|
||
Return | 包含状态和修改成功以后的模型数据/异常信息的json对象 | |
-成功 |
|
|
-失败 |
|
|
备注 | 除非场景特殊,一般通过PATCH的方式进行更新即可 |
多数据查询
一次查询多个模型数据
Method | GET | |
URL | http://{{server_url}}/api/v1.0/{url_prefix}/query_multiple/ | |
Payload | - | |
Return | 包含状态和数据列表/异常信息的json对象 | |
-成功 |
|
|
-失败 |
|
|
备注 | 主要是为了减少请求次数,方便前端使用 |