gRPC 和普通 HTTP API 哪个更适合 APP 客户端与服务器通信？为什么大部分 APP 都还在使用传统 HTTP API？

RT

@drymonfidelia #7
“HTTP2 可以复用连接”
你都说是 HTTP2 了，http api 用不了吗？

“结合 protobuf 压缩效率高提升弱网体验”
protobuf 的压缩效率比 gzip 高多少你测试过吗？

“还可以直接把图片和文字一起传输不用 base64 浪费带宽”
你到底是想省带宽还是浪费带宽？但凡考虑点体验和带宽都会选择把图片放 cdn 吧

要保持长连接，弱网不行，闪断不行。为什么要用这个 xx 玩意

一般使用 http 。主要是因为 grpc 是保持连接的，服务器的连接数是有限制的，使用 grpc 会导致限制了客户端数量。

重点还是根据实际情况而定。

传统 api 也可以 h2
你会问这个问题肯定也用不到 protobuf 对比 json 的提升
你非要图片文字一起传？更不用说对象存储
唯一考虑点就是你要不要服务器主动推数据，一般也是走系统推送

你缺这点带宽么。。

grpc 还没有 http api 应用的那么广泛，但是可以在服务器内部之前大量使用。

grpc 是二进制的，可能在调试的时候比较麻烦？

其实我更想问你为什么会觉得应该用 grpc 而不是 http?

gRPC 对比来说，和 json 或者 xml 都不一样，不是自解释的，必须要搭配着 protocol 文件一起用，就挺麻烦的。
也有可能是大部分开发项目，都在实现功能阶段，远远没有达到优化阶段。

因为大部分 APP 用不到 gRPC 带来的性能提升，反而提高了因为开发维护的难度。都是草台班子，规范的 http-api 就不错了，更别提还有用纯 text 做接口的。（只返回 OK 、ERROR 字符串)