Rest、GraphQL、gRPC,是目前對(duì)Web暴露API常用的三種組織方式。
每當(dāng)看著這些名詞,我都會(huì)進(jìn)入選擇困難癥。這些豐富多彩的協(xié)議填滿了我們的工具箱,同時(shí)也拋出了一個(gè)難題:如果我想要自己的程序健康長(zhǎng)久,就不得不了解它們到底是什么東西。
這很讓人討厭,因?yàn)樗鼈兙拖袷锹萁z螺母的型號(hào),你做的工作只不過(guò)是從一堆零件里挑合適的出來(lái),讓它們配對(duì),并讓它們組合成你想要的功能。
(資料圖片)
很無(wú)趣,也非常沒(méi)有價(jià)值。但看在錢的面子上,又不得不學(xué)。本文就是讓你快速進(jìn)行選擇,不拖泥帶水,趕緊完成工作,喝杯茶也比瞎糾結(jié)有趣的多。
RestRest是最常用的API交互手段,SpringBoot對(duì)其進(jìn)行了高度的集成。它通過(guò)語(yǔ)義化的URL,使用最通用的HTTP協(xié)議,完成無(wú)狀態(tài)的請(qǐng)求交互。
Rest是Restfull的簡(jiǎn)稱,使用HTTP的POST、GET、 PUT、 PATCH 和DELETE來(lái)定義對(duì)資源的操作。
雖然有這么的操作意義,但在平常的使用中,我們習(xí)慣只使用它的POST和GET方法,對(duì)應(yīng)在Spring里就是@GetMapping和@PostMapping注解。沒(méi)別的原因,只因?yàn)镽est看似很強(qiáng)大,但在企業(yè)開(kāi)發(fā)中曲線相對(duì)較高,很多聚合資源和復(fù)雜的操作,根本無(wú)法抽象成資源。
但Rest變種也算Rest,它依然是使用最廣泛的模式。
選擇Rest的原因是因?yàn)樗纳鷳B(tài)太好了。從Ruby到Java、從Golang到Rust,幾乎沒(méi)有語(yǔ)言不支持Rest。如果你想要開(kāi)發(fā)一個(gè)Web系統(tǒng),那幾行代碼,非常容易的就能把你的API暴露出去。而且,它與網(wǎng)關(guān)的集成度非常高,各種負(fù)載均衡組件對(duì)HTTP的協(xié)議可以說(shuō)是爐火純青,如果你選擇它的話,真的是非常的省事。
但是,Rest也意味著效率低下。由于它要兼容HTTP1.0,頻繁的短鏈接也造成了資源的浪費(fèi)。即使是長(zhǎng)鏈接,HTTP臃腫的體積也讓它在追求高性能的場(chǎng)景中稍遜一籌。加上它是無(wú)狀態(tài)的,如果你想傳遞一些伴隨著用戶的數(shù)據(jù)比如JWT Token,那么你不得不放在HTTP Header或者Cookie中,這加重了整體的傳輸負(fù)擔(dān)。
總之,Rest是一個(gè)快速的開(kāi)始,但在高性能、有狀態(tài)的場(chǎng)景下,你不得不選擇其他。
gRPCgRPC當(dāng)然是Google的作品,因?yàn)樗鼈鬏數(shù)臄?shù)據(jù)就是google另外一個(gè)產(chǎn)品protobuf所編碼的。提到gRPC就不得不提到thrift,它們是一樣的東西。但由于google的光環(huán),gRPC更加流行。
gRPC的開(kāi)發(fā)就不像Rest那么靈活,它需要你定義一份合同,然后在client和server端同時(shí)引用和傳輸它。
有了這份合同,就可以壓縮數(shù)據(jù)。比如我們常用的json,其實(shí)冗余信息特別多。如果把json的字段使用固定的int代替,或者放在固定的位置進(jìn)行傳遞,那么字段名稱就根本不需要占用那么大的空間。
gRPC提供了多種數(shù)據(jù)傳輸模式。
類似于Rest的HTTP的一問(wèn)一答模式;Client-Streaming 客戶端發(fā)送數(shù)據(jù)是流的方式,然后以特定信息結(jié)尾,然后Server返回結(jié)果;Server-Streaming Client請(qǐng)求了服務(wù)端,服務(wù)端持續(xù)發(fā)送數(shù)據(jù)到Client,直到通知它結(jié)束;Bidirectional Streaming 雙工通道,那就是普通的TCP鏈接了,全部是流的方式;gRPC發(fā)展了這么多年(2016),對(duì)負(fù)載均衡的支持也非常好。相對(duì)于傳統(tǒng)的Rest,它使用HTTP2來(lái)傳輸數(shù)據(jù),減少了一問(wèn)一答的等待,減少了鏈接的占用。
如果你在搞物聯(lián)網(wǎng),或者一些弱網(wǎng)環(huán)境的數(shù)據(jù)收集,這種高壓縮比的數(shù)據(jù)定然讓你事半功倍。當(dāng)然,如果你的微服務(wù)體系追求較高的性能,結(jié)果Rest就占了一半,那么gRPC是你的不二選擇。
當(dāng)然,弱點(diǎn)也是有的。那就是調(diào)試的時(shí)候,不如HTTP的生態(tài)全面,各種自動(dòng)化工具缺乏,二進(jìn)制也通常會(huì)讓人頭暈?zāi)垦!?/p>GraphQL
GraphQL也比較年輕,到了2015年才誕生,它規(guī)定了一種只取“所需要”數(shù)據(jù)的能力。
在傳統(tǒng)的Rest請(qǐng)求上,訪問(wèn)特定的URL,你會(huì)獲得相對(duì)固定的結(jié)果。不管返回的數(shù)據(jù)里有多少無(wú)用的字段,Rest請(qǐng)求都會(huì)把請(qǐng)求吐給你。
GraphQL的客戶端可以決定取出哪些數(shù)據(jù),甚至是取數(shù)據(jù)的方式和格式--也就是只取它所需要的數(shù)據(jù),而不會(huì)產(chǎn)生過(guò)多的無(wú)用數(shù)據(jù)。
Github就是GraphQL的集大成者。在https://docs.github.com/en/graphql上,詳細(xì)的列出了這些接口。
下面就是一個(gè)典型的帶有變量的查詢語(yǔ)法??梢钥吹?,這使得請(qǐng)求端比如Js有了類似編程的能力。
query($number_of_repos:Int!) { viewer { name repositories(last: $number_of_repos) { nodes { name } } }}variables { "number_of_repos": 3}
當(dāng)然它的弱點(diǎn)也是顯而易見(jiàn)的。相對(duì)于直接請(qǐng)求某個(gè)地址,這些查詢語(yǔ)句使得請(qǐng)求的構(gòu)造變的復(fù)雜,學(xué)習(xí)曲線相對(duì)陡峭。
對(duì)于復(fù)雜的資源查詢,尤其是字段非常多,且層次非常深的資源查詢,GraphQL不失為一種好的方式。
End以上就是這三種主要方式的簡(jiǎn)單介紹。目前,Rest毫無(wú)疑問(wèn)是使用最多的,原因就是因?yàn)楹?jiǎn)單;gRPC有著迅猛的發(fā)展勢(shì)頭,尤其在微服務(wù)領(lǐng)域已經(jīng)得到廣泛應(yīng)用;GraphQL很復(fù)雜,當(dāng)然對(duì)復(fù)雜的業(yè)務(wù)數(shù)據(jù)來(lái)說(shuō)是一個(gè)好的工具。
當(dāng)你的業(yè)務(wù)純粹是功能為主,訪問(wèn)量一般,那就毫無(wú)疑問(wèn)的使用Rest來(lái)快速實(shí)現(xiàn),拿錢完事;如果你的業(yè)務(wù)對(duì)性能要求很高,交互方式上又有流的表現(xiàn)形式,那可以選擇gRPC,這一般發(fā)生在項(xiàng)目初期,否則還是遵循公司的基礎(chǔ)建設(shè)為主;GraphQL就相對(duì)比較高級(jí)了,引入它很痛,周期也較長(zhǎng),是否使用它來(lái)組織數(shù)據(jù),就看你的決心了。
但無(wú)論如何,比起繡花針刺大象,永遠(yuǎn)不要使用大炮打蚊子。那可能轟不著蚊子,而會(huì)炸了自己。
作者簡(jiǎn)介:小姐姐味道 (xjjdog),一個(gè)不允許程序員走彎路的公眾號(hào)。聚焦基礎(chǔ)架構(gòu)和Linux。十年架構(gòu),日百億流量,與你探討高并發(fā)世界,給你不一樣的味道。
標(biāo)簽: Rest
- 當(dāng)前最新:高手,云集在于REST、gRPC 和 GraphQL之間!
- 看點(diǎn):看看服務(wù)網(wǎng)格可以做的所有事情
- 全球熱頭條丨通俗易懂圖解網(wǎng)絡(luò)知識(shí)—第二篇
- 全球新資訊:5G 如何影響數(shù)據(jù)中心以及如何做好準(zhǔn)備
- 今熱點(diǎn):Aruba助力家得寶網(wǎng)絡(luò)煥新升級(jí) 全面提升顧客和員工體驗(yàn)
- 全球即時(shí):Session 和 Cookies 有什么區(qū)別?
- 環(huán)球微速訊:曾經(jīng)5億用戶用過(guò)的社交App即將關(guān)停 原創(chuàng)
- 【環(huán)球熱聞】用了TCP協(xié)議,就一定不會(huì)丟包嗎?
- 速訊:如何設(shè)計(jì)一個(gè)分布式 ID 發(fā)號(hào)器?
- 全球短訊!通俗易懂圖解網(wǎng)絡(luò)面試知識(shí)—第一篇