这篇具有很好参考价值的文章主要介绍了API 风格 （三）：RESTful & gRPC。希望对大家有所帮助。如果存在错误或未考虑完全的地方，请大家不吝赐教，您也可以点击"举报违法"按钮提交疑问。
RESTful VS gRPC
| 对比项 |
RESTful |
gRPC |
| 优点 |
- 相对来说，REST更规范、标准、通用，无论哪种语言都支持 HTTP 协议，可以对接外部很多系统，只要满足 HTTP 调用即可。
- 通常采用 JSON 作为数据通信格式，可读性强，开发调试都很方便。
- 客户端与服务端之间 松耦合，让变更更加方便。
|
- 屏蔽网路细节，像调用本地方法一样，调用远程接口。
- 通常采用 Protocol Buffers 作为数据传输格式，这种格式数据传输效率高。
- 基于 HTTP/2 协议标准，性能更高。
|
| 缺点 |
- 扩展性差：随着需求的变化，单个 RESTful 接口可能会变得越来越臃肿。
- 性能相对于 gRPC 偏低。
|
- Protobuf 数据格式可读性差。
- gRPC 不支持浏览器调用，因此不能用作外部服务。
- 调试不方便，没有像 RESTful 中的 postman 和 curl 之类的调试工具。
|
| 适用场景 |
- 接口对外，需要接口规范易懂。
- 对系统性能要求不高。
- 提供的 API 天生围绕资源、对象、管理展开。
|
- 消息密集型、对系统性能和延时要求比较高。
- 偏向内部的 API。
- 提供的 API 很难就行资源、对象抽象。
|
更多的时候，RESTful API 和 gRPC API 是一种合作的关系，对内业务使用 gRPC API，对外业务使用 RESTful API。
练习
已有一个 gRPC 服务，但是却希望该服务同时也能提供 RESTful API 接口，这该如何实现？
希望用RPC作为内部API的通讯，同时也想对外提供RESTful API，又不想写两套，
可以使用gRPC Gateway 插件，在生成RPC的同时也生成RESTful web server。文章来源：https://www.toymoban.com/news/detail-403690.html
grpc-gateway文章来源地址https://www.toymoban.com/news/detail-403690.html
到了这里，关于API 风格 （三）：RESTful & gRPC的文章就介绍完了。如果您还想了解更多内容，请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章，希望大家以后多多支持TOY模板网！
本文来自互联网用户投稿，该文观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处： 如若内容造成侵权/违法违规/事实不符，请点击违法举报进行投诉反馈，一经查实，立即删除！
