api idea 开发rest_几种API设计方法REST、gRPC、GraphQL及WebHook的对比和选型

最新推荐文章于 2023-11-26 09:00:00 发布

深渊号角mkq

最新推荐文章于 2023-11-26 09:00:00 发布

阅读量175

点赞数

文章标签： api idea 开发rest

本文链接：https://blog.csdn.net/weixin_28947253/article/details/112509832

版权

来源：极链科技作者：刘聪

说到接口的设计大部分人第一个想到的可能是REST；的确，REST是目前最为普遍的一种接口设计方式，并且作为一个优秀的接口设计标准而被广泛使用，但是除此之外，我们也不应该忘记还有其他的选项。除了REST，我们还有rpc(或者grp)，最近大火GraphQL，以及webhooks. 为了好的了解这几种设计以及背后的优缺点，我们一一做简单的介绍。

REST

首先REST--Resource Representational State Transfer, 中文直译就是资源在网络中以某种表现形式进行状态转移；光这么看确实还是比较头大，每个单词拆开可能比较好理解；

Resource：资源，那对于程序来讲就是数据；

Representational：表现形式，我们在web开发中常用的传输类型比如TXT、HTML、JSON、XML、JPEG等；

State Transfer：状态变化，对应的是HTTP协议中的动词(常用的动词如：GET POST PUT PATCH DELETE)；

REST基于HTTP，所以也是无状态的，以HTTP的各种动词来定义约定一系列的URL来操作资源；它描述的是网络中client与server的一种交互形式。

但是我们在谈REST的时候其实并不是谈论REST本身，而是RESTful API，即REST 风格的网络接口设计；来看几个最基础RESTful API的URL：

GET /api/users : 列出所有用户
POST /api/users : 新建一个用户
GET /api/users/ID : 获取一个用户的指定信息
PUT /api/user/ID : 更新某个指定用户的信息(全部信息)
PATH /api/users/ID ：更新某个指定用户的信息(部分信息)
DELETE /api/users/ID : 删除某个用户

从上面的例子我们也可以看出RESTful API的设计的URI使用的基本都是名字，具体动词其实是依赖HTTP中的各个动词来指定不同的动作(这也是在设计RESTful API时容易产生误用的地方，会把动词放在URI上)；

REST的优点也比较明显：客户端与服务器分离，简化服务器逻辑以及提高可伸缩性；无状态，降低服务器资源使用(相对于有状态的长连接)，同时提高服务器的可扩展性；由于不同的信息返回时可以分开标记是否可以缓存，使得客户端可以重用之前的信息，减少客户端与服务端的交互次数。

RPC / gRPC

首先RPC-- Remote Procedure Call(远程过程调用)，相信大家不会陌生，主要是用于服务器之间的方法调用。RPC的本质是提供轻量无感知的跨进程通信方式，与上面基于HTTP的RESTful API并不是对立的，并且应用的场景也有所区别；http的接口优点是简单、直接、开发方便，利用现成http协议进行传输；相对于RPC，如果是基于TCP协议的长连接，不必每次都像http 一样3次握手，减少网络开销；其次一般rpc框架都有注册中心、监控管理，对于服务化架构和服务化治理，RPC框架是一个强力的支撑；RPC低耗、高效的服务调用方式比较适合 IOT 等对资源、带宽、性能敏感的场景。

常用的一些分布式RPC框架有Dubbo、Thrift、RPCx等；不过我们这里并不打算介绍这些框架，主要介绍一下谷歌开源的一个rpc框架：gRPC。

gRPC相对于常用的RPC框架最大的特点是使用了protobufs作为语言格式化数据，进一步提高了序列化和反序列化的速度，同时降低数据包的大小。Protobuf开源已久，它提供了一种灵活、高效、自动序列化结构数据的机制，作用与XML、JSON等格式类似，但是使用二进制传输，序列化/反序列化的速度快，压缩效率高；而且Protobuf有强大的IDL(Interface

Description Language，接口描述语言)和相关的工具，用户写好.proto描述文件之后可以编译成多种语言。

gPRC另外一个特点是使用HTTP2，性能比HTTP1.1好很多，我们也可以简单了解下HTTP2的一些特性，为什么会比HTTP1.1性能好：

新的二进制格式。x都是基于文本解析，而因为文本表现形式的多样性，基于文本协议的格式解析天然存在健壮性的问题，而采用二进制格式后实现方便并且健壮。
多路复用。x每个请求要重新建立新的连接，而且每个浏览器都有会限制单个页面创建的连接数，而在HTTP2.0中多个请求可以复用一个连接。
header压缩。目前x中的header信息每次都会重复发送，造成很大的浪费。HTTP2.0使用encoder减少传输的header 大小，且通信双方都缓存一份包含了header信息的表，伺候的请求只需要发送差异数据，避免重复的传输。

GraphQL

官方定义GraphQL是一种针对API的查询语言也是一个满足你数据查询的运行时。可以理解为另外一个种客户端与服务器之间的交互方式：前端决定后端的返回结果。它的好处是精简响应的内容，不会出现冗余字段，前端需要什么就取什么，而不需要重新定制开发api。GraphQL并不是REST的替代品，官网上有一张图描述了GraphQL与其他几种API设计的关系：