为什么我们要使用protobuf ?
接口联调中常见的问题
最近写接口,和客户端联调比较多,发现了以下几点问题:
接口返回
[ ]
或{ }
的问题
比如正常返回是一个对象,但是如果是空的话,返回的是空数组,此时客户端让我们改为空对象。
这其实是php本身如此。数值 or 字符串?
因为php是弱类型的,有时候会返回字符串类型的数值(如: 1 , '1')
。此时客户端会让我们传指定的数值类型。服务端定好的返回的数据结构,客户端不满足,会让我们调整结构。
比如某个显示,有三个条件满足才显示,此时客户端希望我们提供一个字段控制其显示如否即可。写接口文档
开发者其实都不愿意写文档,我们写好后,后期改了,可能也会忘记调整文档。
以上就是一些常见的问题了。我发现如果使用 protobuf ,可以解决上述问题。
我们来看下 protobuf 的一些优点吧。
使用 protobuf 的优点
protobuf 是基于二进制传输的,所以他比json更安全。并且同样的数据,因为 protobuf 不需要字段名称。传输量更小,省带宽,性能好。
protobuf 传输数据前,是需要根据我们定好的格式,效验数据类型和数据结构的,所以如果数据类型不对,或者少字段,则在传输到客户端前,就截断了,并告诉后端是什么原因。这样就解决了上面的
1,2问题
protobuf 是可以双方协作定好接口返回结构的,避免了上述的
问题3
写 protobuf 时,可以顺手把字段的注释加上,省掉了写接口文档的烦恼。
给大家看一个 protobuf 文件的示例
syntax = "proto3";
package proto.club;
/*xx请求*/
message ClubListReq {
base.ReqCode cmd = 1;
base.ExtReq ext = 2;
uint32 page = 3; // 页码
optional string keyword = 4; // 搜索关键字,可选
}
/*xx返回*/
message ClubListRsp {
base.RspCode cmd = 1;
base.ExtRsp ext = 2;
uint32 page = 3;
uint32 totalPage = 4;
repeated ClubInfo clubList = 5; // 家族列表 [{}, {}, ...]
}
本作品采用《CC 协议》,转载必须注明作者和本文链接
推荐文章: