现在开发的项目，尤其是管理后台的项目，CURD操作是非常频繁的，如果接口约定的不好，后端就需要开发各种Api，前端人员也需要在Api文件中添加多个Api，开发成本不知不觉就增加了。
所以，针对比较普遍的CURD操作，前后端在接口上就需要制定一些约定。
一、添加和修改
1.添加操作和修改操作约定成一个接口。
添加一般情况下是没有ID的，修改一般情况下是有ID的。两个操作的其他字段其实都是一样的。
//前端请求
req = {
data:{
videoId:'', //如果是修改则不为空
videoName:'视频名称',
videoStatus:0 //0下线，1上线
},
source:'pc', //请求接口的客户端
token:'123' //请求接口的token，一般登录后会由后端返回
}
//后端返回
res = {
code:200,
msg:'success'
}
2.修改操作，对于能修改的字段，全部开放给前端。
比如：修改视频的基本信息，和修改视频的上下线操作。对于前端来说，可能是两个操作，但是后端的接口其实都是修改操作，不需要为了一个上下线操作重新定制一个接口。
//前端请求
req = {
data:{
videoId:'123 ', //如果是修改则不为空
videoName:'',
videoStatus:1 //0下线，1上线
},
source:'pc', //请求接口的客户端
token:'123' //请求接口的token，一般登录后会由后端返回
}
//后端返回
res = {
code:201,
msg:'修改失败:视频名称不能为空'
}
二、删除操作
1.删除操作接口约定成批量删除
删除操作一般情况下都是删除指定ID的数据，但是很多时候，产品会在后期才提出批量删除的需求，因为前期数据比较少。
所以删除的接口约定成批量删除，单个数据删除，数组只有一个ID。
//前端请求
req = {
data:{
ids:['123'] //如果是批量删除 ids:['123','456','789']
},
source:'pc', //请求接口的客户端
token:'123' //请求接口的token，一般登录后会由后端返回
}
//后端返回
res = {
code:200,
msg:'success'
}
三、查询操作
1.查询操作接口约定成多条件查询。
查询操作的使用场景是非常多的，对于特定的查询条件，比如某个主题下的所有视频，将其他查询条件置空即可。
// 前端请求
req = {
data:{
videoName:'', //视频名称 模糊查询
pageId:0,
pageSize:10 //每页数据的条数
},
source:'pc', //请求接口的客户端
token:'123' //请求接口的token，一般登录后会由后端返回
}
//后端返回
res = {
code:200,
msg:'success',
data:{
total:100,
list:[{
videoId:'123',
videoName:'视频名称',
videoStatus:0
}
...
]
}
}
2.查询操作全部约定成列表返回。
比如很多时候需要查询某个视频，往往会定制一个getVideo的接口，然后查询参数是videoId，如果是多条件查询，就不需要这个接口了。当然根据某个videoId查询出的列表，数组长度只有一个而已，所以取list[0]即可。
// 前端请求
req = {
data:{
videoId:'123', //查询某个视频，往往是修改信息的时候需要
pageId:0,
pageSize:1 //每页数据的条数
},
source:'pc', //请求接口的客户端
token:'123' //请求接口的token，一般登录后会由后端返回
}
//后端返回
res = {
code:200,
msg:'success',
data:{
total:1,
list:[{
videoId:'123',
videoName:'视频名称',
videoStatus:0
}
]
}
}
3.查询操作约定成分页的。
查询操作约定成分页的，将其查询结果的总条数返回给前端，方便其分页。
一般情况下前端分页需要列表数据，查询数据总条数，每页显示条数，就可以计算出总页码数，当前页码不需要返回。
四、对于比较特殊的接口，前后端开发人员需要自己约定，其原则是通用可行。
网友评论