REST, GraphQL, Webhooks & gRPC 如何选型

Posted 21CTO

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了REST, GraphQL, Webhooks & gRPC 如何选型相关的知识,希望对你有一定的参考价值。

1 引言

每当项目进入联调阶段,或者提前约定接口时,前后端就会聚在一起热火朝天的讨论起来。可能 99% 的场景都在约定 Http 接口,讨论 URL 是什么,入参是什么,出参是什么。

有的团队前后端接口约定更加高效,后端会拿出接口定义代码,前端会转换成(或自动转成)Typescript 定义文件。

但这些工作都针对于 Http 接口,今天通过 when-to-use-what-rest-graphql-webhooks-grpc 一文,抛开联调时千遍一律的 Http 接口,一起看看接口还可以怎么约定,分别适用于哪些场景,你现在处于哪个场景。

2 概述

本文主要讲了四种接口设计方案,分别是:REST、gRPC、GraphQL、Webhooks,下面分别介绍一下。

REST

REST 也许是最通用,也是最常用的接口设计方案,它是 无状态的,以资源为核心,针对如何操作资源定义了一系列 URL 约定,而操作类型通过 GET POST PUT DELETE 等 HTTP Methods 表示。

REST 基于原生 HTTP 接口,因此改造成本很小,而且其无状态的特性,降低了前后端耦合程度,利于快速迭代。

随着未来发展,REST 可能更适合提供微服务 API。

使用举例:

curl -v -X GET https://api.sandbox.paypal.com/v1/activities/activities?start_time=2012-01-01T00:00:01.000Z&end_time=2014-10-01T23:59:59.999Z&page_size=10 \ -H "Content-Type: application/json" \-H "Authorization: Bearer Access-Token"

gRPC

gRPC 是对 RPC 的一个新尝试,最大特点是使用 protobufs 语言格式化数据。

RPC 主要用来做服务器之间的方法调用,影响其性能最重要因素就是 序列化/反序列化 效率。RPC 的目的是打造一个高效率、低消耗的服务调用方式,因此比较适合 IOT 等对资源、带宽、性能敏感的场景。而 gRPC 利用 protobufs 进一步提高了序列化速度,降低了数据包大小。

使用举例:

gRPC 主要用于服务之间传输,这里拿 Nodejs 举例:

1.定义接口。由于 gRPC 使用 protobufs,所以接口定义文件就是 helloword.proto:

// The greeting service definition.service Greeter {  // Sends a greeting  rpc SayHello (HelloRequest) returns (HelloReply) {}  // Sends another greeting  rpc SayHelloAgain (HelloRequest) returns (HelloReply) {} }// The request message containing the user's name.message HelloRequest {  string name = 1; }// The response message containing the greetingsmessage HelloReply {  string message = 1; }

这里定义了服务 Greeter,拥有两个方法:SayHello 与 SayHelloAgain,通过 message 关键字定义了入参与出参的结构。

事实上利用 protobufs,传输数据时仅传送很少的内容,作为代价,双方都要知道接口定义规则才能序列化/反序列化。

2.定义服务器:

function sayHello(call, callback) {  callback(null, { message: "Hello " + call.request.name }); }function sayHelloAgain(call, callback) {  callback(null, { message: "Hello again, " + call.request.name }); }function main() {  var server = new grpc.Server();  server.addProtoService(hello_proto.Greeter.service, {    sayHello: sayHello,    sayHelloAgain: sayHelloAgain  });  server.bind("0.0.0.0:50051", grpc.ServerCredentials.createInsecure());  server.start(); }

我们在 50051 端口支持了 gRPC 服务,并注册了服务 Greeter,并对 sayHello sayHelloAgain 方法做了一些业务处理,并返回给调用方一些数据。

3.定义客户端:

function main() {  var client = new hello_proto.Greeter(    "localhost:50051",    grpc.credentials.createInsecure()  );  client.sayHello({ name: "you" }, function(err, response) {    console.log("Greeting:", response.message);  });  client.sayHelloAgain({ name: "you" }, function(err, response) {    console.log("Greeting:", response.message);  }); }

可以看到,客户端和服务端同时需要拿到 proto 结构,客户端数据发送也要依赖 proto 包提供的方法,框架会内置做掉序列化/反序列化的工作。

也有一些额外手段将 gRPC 转换为 http 服务,让网页端也享受到其高效、低耗的好处。但是不要忘了,RPC 最常用的场景是 IOT 等硬件领域,网页场景也许不会在乎节省几 KB 的流量。

GraphQL

GraphQL 不是 REST 的替代品,而是另一种交互形式:前端决定后端的返回结果。

GraphQL 带来的最大好处是精简请求响应内容,不会出现冗余字段,前端可以决定后端返回什么数据。但要注意的是,前端的决定权取决于后端支持什么数据,因此 GraphQL 更像是精简了返回值的 REST,而后端接口也可以一次性定义完所有功能,而不需要逐个开发。

再次强调,相比 REST 和 gRPC,GraphQL 是由前端决定返回结果的反模式。

使用举例:

原文推荐参考 GitHub GraphQL API

比如查询某个组织下的成员,REST 风格接口可能是:

curl -v https://api.github.com/orgs/:org/members

含义很明确,但问题是返回结果不明确,必须实际调试才知道。换成等价的 GraphQL 是这样的

query {  organization(login: "github") {    members(first: 100) {      edges {        node {          name          avatarUrl        }      }    }  } }

返回的结果和约定的格式结构一致,且不会有多余的字段:

{  "data": {   
 "organization": {  
    "members": {      
      "edges": [          {        
         "node": {  
                     "name": "Chris Wanstrath",
                     "avatarUrl": "https://avatars0.githubusercontent.com/u/2?v=4"            }          },          {
                     "node": {
                            "name": "Justin Palmer",              "avatarUrl": "https://avatars3.githubusercontent.com/u/25?v=4"            }          }        ]      }    }  } }

但是能看出来,这样做需要一个系统帮助你写 query,很多框架都提供这个功能,比如 apollo-client。

Webhooks

如果说 GraphQL 颠覆了前后端交互模式,那 Webhooks 可以说是彻头彻尾的反模式了,因为其定义就是,前端不主动发送请求,完全由后端推送。

它最适合解决轮询问题。或者说轮询就是一种妥协的行为,当后端不支持 Webhooks 模式时。

使用举例:


最后作者给出的结论是,这四个场景各有不同使用场景,无法相互替代:

  • REST:无状态的数据传输结构,适用于通用、快速迭代和标准化语义的场景。

  • gRPC:轻量的传输方式,特殊适合对性能高要求或者环境苛刻的场景,比如 IOT。

  • GraphQL: 请求者可以自定义返回格式,某些程度上可以减少前后端联调成本。

  • Webhooks: 推送服务,主要用于服务器主动更新客户端资源的场景。

3 精读

REST 并非适用所有场景

本文给了我们一个更大的视角看待日常开发中的接口问题,对于奋战在一线的前端同学,接触到 90% 的接口都是非 REST 规则的 Http 接口,能真正落实 REST 的团队其实非常少。这其实暴露了一个重要问题,就是 REST 所带来的好处,在整套业务流程中到底占多大的比重?

不仅接口设计方案的使用要分场景,针对某个接口方案的重要性也要再继续细分:在做一个开放接口的项目,提供 Http 接口给第三方使用,这时必须好好规划接口的语义,所以更容易让大家达成一致使用 REST 约定;而开发一个产品时,其实前后端不关心接口格式是否规范,甚至在开发内网产品时,性能和冗余都不会考虑,效率放在了第一位。所以第一点启示是,不要埋冤当前团队业务为什么没有使用某个更好的接口约定,因为接口约定很可能是业务形态决定的,而不是凭空做技术对比从而决定的。

gRPC 是服务端交互的首选

前端同学转 node 开发时,很喜欢用 Http 方式进行服务器间通讯,但可能会疑惑,为什么公司内部 Java 或者 C++ 写的服务都不提供 Http 方式调用,而是另外一个名字。了解 gRPC 后,可以认识到这些平台都是对 RPC 方式的封装,服务器间通信对性能和延时要求非常高,所以比较适合专门为性能优化的 gRPC 等服务。

GraphQL 需要配套

GraphQL 不是 REST 的替代品,所以不要想着团队从 Http 接口迁移到 GraphQL 就能提升 X% 的开发效率。GraphQL 方案是一种新的前后端交互约定,所以上手成本会比较高,同时,为了方便前端同学拼 query,等于把一部分后端工作量转移给了前端,如果此时没有一个足够好用的平台快速查阅、生成、维护这些定义,开发效率可能不升反降。

总的来说,对外开放 API 或者拥有完整配套的场景,使用 GraphQL 是比较理想的,但对于快速迭代,平台又不够成熟的团队,继续使用标准 Http 接口可以更快完成项目。

Webhooks 解决特殊场景问题

对于第三方平台验权、登陆等 没有前端界面做中转的场景,或者强安全要求的支付场景等,适合用 Webhooks 做数据主动推送。说白了就是在前端无从参与,或者因为前端安全问题不适合参与时,就是 Webhooks 的场景。很显然 Webhooks 也不是 Http 的替代品,不过的确是一种新的前后端交互方式。

对于慢查询等场景,前端普遍使用轮询完成,这和 Socket 相比体验更弱,但无状态的特性反而会降低服务器负担,所以慢查询和即时通讯要区分对待,用户对消息及时性的敏感程度决定了使用哪种方案。

4 总结

最后,上面总结的内容一定还有许多疏漏,欢迎补充。


译者:黄子毅

原文:https://nordicapis.com/when-to-use-what-rest-graphql-webhooks-grpc/

以上是关于REST, GraphQL, Webhooks & gRPC 如何选型的主要内容,如果未能解决你的问题,请参考以下文章

云原生架构 - 另一种 API 范式 GraphQL

基于场景选择微服务的API范式:RESTGraphQLWebhooks和gRPC

PayPal:IPN/REST/Webhooks 与 Java 程序的集成

使用 REST 包装 GraphQL 从 NestJS 提供 GraphQL 和 REST API

GraphQL 优于 REST?

REST 映射到 GraphQL