服务器端和客户端开发对接总结
1.从服务器端开发角度而言,将尽可能多的业务在服务器端处理,客户端尽可能少地处理业务逻辑,只做展示使用即可.原因在于服务器端开发一定了解业务,如果让客户端和服务器端都很精通业务,那么就会耗费不必要的时间;
2.从客户端端开发角度而言,服务器端每次返回的数据都是完整版数据,即如果没有对应的数据,那么某些字段也不可以没有返回,可以两方面约定好,不做业务上的判断处理,但是要对字符串,数字,时间做无数据的替换,比如字符串用空字符串,整数使用0,浮点数使用0.0,时间使用格林威治的初始时间,然后根据产品意见替换特殊的数据,比如数字为0,浮点数为0.0,都可以使用--代替等,为何如此呢?因为如果直接返回0或者0.0或者其他数值,那么客户端直接展示数据,但是这却是错误数据,客户端可能说服务器给的值,我就直接展示啦,当然问题在于服务器端;但是如果不给完整的数据,客户端又要进行重要的业务判断,需要了解大量业务流程,所以这种处理客户端只需要判断数据是否存在即可!
3.从两者角度而言,必须预定好返回值格式.比如:
{
code:数字,
msg:"",
subCode:数字,
subMsg:"",
data:{
}
}
code:系统级code,msg:系统级消息,subCode:业务级code,subMsg:业务消息,data是业务数据.
data中内容必须是name-value格式,否则对于客户端无法进行解析.
3.1比如如果返回是数组内容,
{
code:200,
msg:"queryUser调用成功",
subCode:200,
subMsg:"查询用户成功",
data:{
"list":[{"name":"哈哈1"},{"name":"哈哈2"},{"name":"哈哈3"}],
"list_name":"查询用户"
}
}
而不可以写
{
code:200,
msg:"queryUser调用成功",
subCode:200,
subMsg:"查询用户成功",
data:{
[{"name":"哈哈1"},{"name":"哈哈2"},{"name":"哈哈3"}]
}
}
这样客户端无法解析,因为没有name值.
3.2例如返回用户数据内容
{
code:200,
msg:"queryUser调用成功",
subCode:200,
subMsg:"查询用户成功",
data:{
"name":"张三",
"sex":1,
"age":12
}
}
3.3如果处理失败,那么客户端可以不做处理,拿出服务器端返回的错误细心进行展示即可,那么此时可以不用解析data数据
比如:
{
code:404,
msg:"queryUser调用成功",
subCode:404,
subMsg:"查询用户成功",
data:null
}
此时如果按照正常返回值处理,那么data绝对不可以为null.但是此时请求处理失败,那么客户端可以不用解析data数据,直接返回subMsg信息给用户即可!
3.4对于code数值代表的含义而言,这个需要服务器端开发人员定义好之后告诉客户端开发,一旦约定好不可以进行修改变动,如果开发的app过大的时候,接口众多的时候.
4.从服务器角度而言,如果服务器端开发的接口返回值需要从很多系统获取,即调用非常多的接口才能返回一个完整的数据,此时是使用多个接口每个接口返回部分数据,还是使用单个接口返回全部数据呢?使用后者,为何如此呢?只是针对客户端开发而言,客户端进行页面布局的时候使用,否则出来的数据不完整,页面布局会失败,用户体验性不好;同时接口调用同步和异步方式,如果多个接口调用再返回数据,会出现数据不完整,界面布局失败的问题.
例如用户订单问题,订单中有附件,用户,交易流水,用户地址,产品信息,优惠券信息等等,适合使用一个接口返回全部数据!如果不一个接口返回,那么就要求一个接口返回!
1.从服务器端开发角度而言,将尽可能多的业务在服务器端处理,客户端尽可能少地处理业务逻辑,只做展示使用即可.原因在于服务器端开发一定了解业务,如果让客户端和服务器端都很精通业务,那么就会耗费不必要的时间;
2.从客户端端开发角度而言,服务器端每次返回的数据都是完整版数据,即如果没有对应的数据,那么某些字段也不可以没有返回,可以两方面约定好,不做业务上的判断处理,但是要对字符串,数字,时间做无数据的替换,比如字符串用空字符串,整数使用0,浮点数使用0.0,时间使用格林威治的初始时间,然后根据产品意见替换特殊的数据,比如数字为0,浮点数为0.0,都可以使用--代替等,为何如此呢?因为如果直接返回0或者0.0或者其他数值,那么客户端直接展示数据,但是这却是错误数据,客户端可能说服务器给的值,我就直接展示啦,当然问题在于服务器端;但是如果不给完整的数据,客户端又要进行重要的业务判断,需要了解大量业务流程,所以这种处理客户端只需要判断数据是否存在即可!
3.从两者角度而言,必须预定好返回值格式.比如:
{
code:数字,
msg:"",
subCode:数字,
subMsg:"",
data:{
}
}
code:系统级code,msg:系统级消息,subCode:业务级code,subMsg:业务消息,data是业务数据.
data中内容必须是name-value格式,否则对于客户端无法进行解析.
3.1比如如果返回是数组内容,
{
code:200,
msg:"queryUser调用成功",
subCode:200,
subMsg:"查询用户成功",
data:{
"list":[{"name":"哈哈1"},{"name":"哈哈2"},{"name":"哈哈3"}],
"list_name":"查询用户"
}
}
而不可以写
{
code:200,
msg:"queryUser调用成功",
subCode:200,
subMsg:"查询用户成功",
data:{
[{"name":"哈哈1"},{"name":"哈哈2"},{"name":"哈哈3"}]
}
}
这样客户端无法解析,因为没有name值.
3.2例如返回用户数据内容
{
code:200,
msg:"queryUser调用成功",
subCode:200,
subMsg:"查询用户成功",
data:{
"name":"张三",
"sex":1,
"age":12
}
}
3.3如果处理失败,那么客户端可以不做处理,拿出服务器端返回的错误细心进行展示即可,那么此时可以不用解析data数据
比如:
{
code:404,
msg:"queryUser调用成功",
subCode:404,
subMsg:"查询用户成功",
data:null
}
此时如果按照正常返回值处理,那么data绝对不可以为null.但是此时请求处理失败,那么客户端可以不用解析data数据,直接返回subMsg信息给用户即可!
3.4对于code数值代表的含义而言,这个需要服务器端开发人员定义好之后告诉客户端开发,一旦约定好不可以进行修改变动,如果开发的app过大的时候,接口众多的时候.
4.从服务器角度而言,如果服务器端开发的接口返回值需要从很多系统获取,即调用非常多的接口才能返回一个完整的数据,此时是使用多个接口每个接口返回部分数据,还是使用单个接口返回全部数据呢?使用后者,为何如此呢?只是针对客户端开发而言,客户端进行页面布局的时候使用,否则出来的数据不完整,页面布局会失败,用户体验性不好;同时接口调用同步和异步方式,如果多个接口调用再返回数据,会出现数据不完整,界面布局失败的问题.
例如用户订单问题,订单中有附件,用户,交易流水,用户地址,产品信息,优惠券信息等等,适合使用一个接口返回全部数据!如果不一个接口返回,那么就要求一个接口返回!
版权声明:本文为mediocre117原创文章,遵循CC 4.0 BY-SA版权协议,转载请附上原文出处链接和本声明。