摘要:而利用進一步提高了序列化速度,降低了數據包大小。帶來的最大好處是精簡請求響應內容,不會出現冗余字段,前端可以決定后端返回什么數據。再次強調,相比和,是由前端決定返回結果的反模式。請求者可以自定義返回格式,某些程度上可以減少前后端聯調成本。
1 引言
每當項目進入聯調階段,或者提前約定接口時,前后端就會聚在一起熱火朝天的討論起來。可能 99% 的場景都在約定 Http 接口,討論 URL 是什么,入參是什么,出參是什么。
有的團隊前后端接口約定更加高效,后端會拿出接口定義代碼,前端會轉換成(或自動轉成)Typescript 定義文件。
但這些工作都針對于 Http 接口,今天通過 when-to-use-what-rest-graphql-webhooks-grpc 一文,拋開聯調時千遍一律的 Http 接口,一起看看接口還可以怎么約定,分別適用于哪些場景,你現在處于哪個場景。
2 概述本文主要講了四種接口設計方案,分別是:REST、gRPC、GraphQL、Webhooks,下面分別介紹一下。
RESTREST 也許是最通用,也是最常用的接口設計方案,它是 無狀態的,以資源為核心,針對如何操作資源定義了一系列 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 greetings message 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 模式時。
使用舉例:
Webhooks 本身也可以由 REST 或者 gRPC 實現,所以就不貼代碼了。舉個常用例子,比如你的好友發了一條朋友圈,后端將這條消息推送給所有其他好友的客戶端,就是 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 總結最后,上面總結的內容一定還有許多疏漏,歡迎補充。
5 更多討論討論地址是:精讀《REST, GraphQL, Webhooks, & gRPC 如何選型》 · Issue #102 · dt-fe/weekly
如果你想參與討論,請點擊這里,每周都有新的主題,周末或周一發布。
文章版權歸作者所有,未經允許請勿轉載,若此文章存在違規行為,您可以聯系管理員刪除。
轉載請注明本文地址:http://specialneedsforspecialkids.com/yun/97628.html
摘要:前端日報精選使用實現和交互的彈幕效果類型檢測理解的閉包深入理解之代理和反射,和它們在之中的優先級中文譯區塊鏈是如何工作的用演示知乎專欄譯怎樣處理移動端對圖片資源的限制掘金技術周刊的正則表達式掘金開發環境搭建掘金與復雜業務組件的 2017-09-11 前端日報 精選 使用canvas實現和HTML5 video交互的彈幕效果【JS】類型檢測理解 JavaScript 的閉包深入理解ES6...
摘要:前端每周清單第期微服務實踐,與,組件技巧,攻防作者王下邀月熊編輯徐川前端每周清單專注前端領域內容,以對外文資料的搜集為主,幫助開發者了解一周前端熱點分為新聞熱點開發教程工程實踐深度閱讀開源項目巔峰人生等欄目。 前端每周清單第 26 期:Node.js 微服務實踐,Vue.js 與 GraphQL,Angular 組件技巧,HeadlessChrome 攻防 作者:王下邀月熊 編輯:徐川...
摘要:感謝王下邀月熊分享的前端每周清單,為方便大家閱讀,特整理一份索引。王下邀月熊大大也于年月日整理了自己的前端每周清單系列,并以年月為單位進行分類,具體內容看這里前端每周清單年度總結與盤點。 感謝 王下邀月熊_Chevalier 分享的前端每周清單,為方便大家閱讀,特整理一份索引。 王下邀月熊大大也于 2018 年 3 月 31 日整理了自己的前端每周清單系列,并以年/月為單位進行分類,具...
摘要:一份開發者必備的技能清單,請查收。入門查漏補缺深入學習查看原圖下載源文件使用快速上手,并了解其中的概念。官方教程入門教程小書文章精讀,問題解答。 一份react開發者必備的技能清單,請查收。入門、查漏補缺、深入學習... showImg(https://segmentfault.com/img/remote/1460000018000950?w=1965&h=3332); 查看原圖 ...
閱讀 1626·2021-10-14 09:43
閱讀 5503·2021-09-07 10:21
閱讀 1275·2019-08-30 15:56
閱讀 2123·2019-08-30 15:53
閱讀 1231·2019-08-30 15:44
閱讀 2010·2019-08-30 15:44
閱讀 1320·2019-08-29 17:24
閱讀 752·2019-08-29 15:19