day5 - API接口设计: gRPC & http API 简介

当你把产品包装好之後, 要怎麽销售出去呢？

『销售』套用在系统开发上面就是怎麽让外部的系统能够使用到自己开发好的功能, 我们会把开放功能的方式称作开API接口。API接口就像是到麦当劳点餐时帮忙服务的柜台人员, 消费者告诉柜台要点什麽餐, 柜台再依照餐点内容逐一核对细项并过滤掉非销售的商品, 统整好内容再传达给负责的人员, 等到负责人员回覆餐点之後再由柜台人员传递给客人, 这就是一个API沟通的过程。

目前处理过的API提供方式有RESTful API 跟 gRPC API, 大致上会用对内跟对外来区分要采用哪个, RESTFUL API 主要用在跟外部厂商沟通使用, gRPC API则是内部专案沟通使用。

gRPC vs HTTP API简介

• gRPC

  gRPC 使用 Protobuf 序列化进行资料传输, 走的是RPC协定, 因为传输的资料切分的很小, 传输的速度很快, 是目前我们主要使用的沟通方式, 它无法被浏览器呼叫到, 但可以安装gRPCurl来测试。
  使用gRPC时, Client端也要有一份proto才能正确打到服务, 服务也必须依照proto制定的格式来接收跟传送, 由於双方都是以proto做依据, 所以只要制定好proto之後, Client端就可以同步进行API介接, 这样不只缩短了开发过程中来来回回确认格式的状况, 也减少了介接API时发生图文不符的状况。缺点是每次异动proto之後, 如果client 端需要使用到新的spec内容就必须更新一次proto, 这也是为什麽他不适合用在跟外部厂商沟通。

• HTTP

  HTTP API 是依照RESTful规范设计的API, 走的是HTTP协定, 它可以透过浏览器打到API, 是最常见的API设计。它适用在团队之外的沟通方式, 大多数的语言都有支持RESTful API, 只要server修改格式之後, client不需要更新其他项目就可以拿到新的API内容, 它的传输格式都是由工程师透过文件说明的, 由於它不像gRPC要符合spec才可以正确的输出跟取得资料, 相较之下容易发生API图文不符的状况。

本次模拟会以gRPC API来开发, gRPC接口也可以透过一些手法同时实作出http接口, 例如使用grpc-gateway或自行包装http router 转换到grpc实作接口也可以, 它可以同时提供两种类型来满足不同的需求。