API 风格 (三):RESTful & gRPC

RESTful  VS  gRPC

对比项RESTfulgRPC
优点
  • 相对来说,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。

    grpc-gateway

  • 1
    点赞
  • 2
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值