MIX Fold3包裝盒泄露 新機(jī)本月登場(chǎng)
小米的全新折疊屏旗艦MIX Fold3將于本月發(fā)布，近日該機(jī)的真機(jī)包裝盒在網(wǎng)上泄露。從圖上來(lái)看，新的MIX Fold3包裝盒在外觀設(shè)計(jì)方面延續(xù)了之前的方案，變化不大，這也是目前小米旗艦
譯者 | 李睿
審校 | 重樓
本文對(duì)gRPC和REST的特征和區(qū)別進(jìn)行了介紹，這可能是當(dāng)今創(chuàng)建API最常用的兩種方法。
以下將從這兩種工具的特征開(kāi)始，也就是它們是什么以及提供什么功能。然后，將根據(jù)七個(gè)方面對(duì)它們進(jìn)行比較，這對(duì)現(xiàn)代系統(tǒng)來(lái)說(shuō)是最重要的7個(gè)類(lèi)別。
其類(lèi)別如下：
（1）底層HTTP協(xié)議
（2）支持的數(shù)據(jù)格式
（3）數(shù)據(jù)大小
（4）吞吐量
（5）定義
（6）易于采用
（7）工具支持
當(dāng)人們聽(tīng)到API時(shí)，可能馬上想到REST API。然而，REST是構(gòu)建API的眾多方法之一。它并不是適用于所有用例的靈丹妙藥。還有其他方法，遠(yuǎn)程過(guò)程調(diào)用 (RPC)只是其中之一，而gRPC可能是使用RPC最成功的框架。
盡管gRPC是一種相當(dāng)成熟和高效的技術(shù)，但它仍然被視為一種新技術(shù)。因此，盡管在某些用例中非常方便，但它沒(méi)有REST被廣泛采用。
本文主要介紹gRPC，并指出它可以發(fā)揮作用的用例。
表述性狀態(tài)轉(zhuǎn)移（REST）可能是創(chuàng)建公開(kāi)任何類(lèi)型API的應(yīng)用程序的最常用方法。它使用HTTP作為底層通信媒介。正因?yàn)槿绱?，它可以從HTTP的所有優(yōu)點(diǎn)中獲益，例如緩存。
REST的兩個(gè)關(guān)鍵概念是：
（1）端點(diǎn)：表示特定資源的唯一統(tǒng)一資源定位符(URL)；可以看作是通過(guò)互聯(lián)網(wǎng)訪問(wèn)特定操作或數(shù)據(jù)元素的一種方式。
（2）資源：在特定URL下可用的特定數(shù)據(jù)塊。
此外，還有一個(gè)叫做Richardson成熟模型的描述——這是一個(gè)描述REST API中“專(zhuān)業(yè)性”程度的模型。它根據(jù)特定API具有的特征集將REST API劃分為3個(gè)級(jí)別(或4個(gè)級(jí)別，取決于是否將級(jí)別0計(jì)算在內(nèi))。
其中一個(gè)特征是REST端點(diǎn)應(yīng)該在URL中使用名詞，并使用正確的HTTP請(qǐng)求方法來(lái)管理其資源。
至于HTTP方法及其相關(guān)操作，如下所示：
成熟度模型規(guī)定的遠(yuǎn)不止這些。例如稱(chēng)為HyperMedi的概念。HyperMedia將數(shù)據(jù)的呈現(xiàn)和對(duì)客戶(hù)端可以執(zhí)行的操作的控制結(jié)合在一起。
對(duì)成熟度模型的完整描述超出了本文的范圍。
gRPC是遠(yuǎn)程過(guò)程調(diào)用（RPC）這個(gè)相對(duì)古老的概念的另一種實(shí)現(xiàn)。谷歌的開(kāi)發(fā)人員創(chuàng)建了它，這就是為什么它的名稱(chēng)里有“g”的原因。它可能是處理RPC最現(xiàn)代和最有效的工具，也是CNCF孵化項(xiàng)目。
gRRC使用谷歌公司的協(xié)議緩沖區(qū)作為序列化格式，同時(shí)利用HTTP/2作為傳輸介質(zhì)數(shù)據(jù)，盡管gRPC也可以使用JSON作為數(shù)據(jù)層。
①Unary：經(jīng)典的請(qǐng)求-響應(yīng)模型，該方法接受輸入并返回輸出。
②服務(wù)器流：該方法接受消息作為輸入，同時(shí)返回消息流作為輸出。gRPC保證了單個(gè)RPC調(diào)用中的消息排序。
③客戶(hù)端流：該方法將消息流作為輸入，處理它們直到?jīng)]有消息為止，然后返回一條消息作為輸出。與上面類(lèi)似，gRPC保證在單個(gè)RPC調(diào)用中進(jìn)行消息排序。
④雙向流：該方法將消息流作為輸入，并將消息流作為輸出返回，有效地使用了讀和寫(xiě)兩個(gè)消息流。兩個(gè)流都獨(dú)立運(yùn)行，并且將消息順序保留在流級(jí)別上。
gRPC API定義以.proto文件的形式編寫(xiě)，其中包含上述所有三個(gè)基本構(gòu)建塊。此外，gRPC提供了一個(gè)協(xié)議緩沖區(qū)編譯器，它從.proto文件生成客戶(hù)端和服務(wù)代碼。
用戶(hù)可以隨心所欲地實(shí)現(xiàn)服務(wù)器端方法，必須堅(jiān)持使用API的輸入輸出契約。
在客戶(hù)端，有一個(gè)叫做客戶(hù)端(或stub)的對(duì)象——類(lèi)似于HTTP客戶(hù)端。它知道來(lái)自服務(wù)器的所有方法，只處理調(diào)用遠(yuǎn)程過(guò)程并返回它們的響應(yīng)。
（1）底層HTTP協(xié)議
這是第一類(lèi)，可能也是最重要的一類(lèi)，因?yàn)樗挠绊懸部梢栽谄渌矫婵吹健?/span>
一般來(lái)說(shuō)，REST是基于請(qǐng)求-響應(yīng)的，并使用HTTP/1.1作為傳輸媒介。這里必須使用不同的協(xié)議，例如WebSocket或任何類(lèi)型的流或更持久的連接。
還可以實(shí)現(xiàn)一些簡(jiǎn)單的代碼，使REST看起來(lái)像消息流。更重要的是，使用HTTP/1.1 REST需要每個(gè)請(qǐng)求-響應(yīng)交換一個(gè)連接。對(duì)于長(zhǎng)時(shí)間運(yùn)行的請(qǐng)求，或者當(dāng)網(wǎng)絡(luò)容量有限時(shí)，這種方法可能會(huì)有問(wèn)題。
當(dāng)然，可以使用HTTP/2來(lái)構(gòu)建類(lèi)似REST的API；然而，并不是所有的服務(wù)器和庫(kù)都支持HTTP/2。因此，其他地方可能會(huì)出現(xiàn)問(wèn)題。
另一方面，gRPC只使用HTTP/2。它允許通過(guò)單個(gè)TCP連接發(fā)送多個(gè)請(qǐng)求-響應(yīng)對(duì)。這種方法可以顯著地提高應(yīng)用程序的性能。
（2）支持的數(shù)據(jù)格式
假設(shè)REST API使用HTTP/1.1的默認(rèn)情況，那么它可以支持多種格式。
REST通常不對(duì)消息格式和樣式施加任何限制?；旧希魏我环N可以序列化為普通舊文本的格式都是有效的。用戶(hù)可以在特定場(chǎng)景中使用最適合自己的任何格式。
在REST應(yīng)用程序中發(fā)送數(shù)據(jù)的最流行格式無(wú)疑是JSON。XML排在第二位，因?yàn)橛写罅康妮^舊/遺留應(yīng)用程序。
然而，當(dāng)使用REST和HTTP/2時(shí)，只支持二進(jìn)制交換格式。在這種情況下，可以使用Protobuf或Avro。當(dāng)然，這種方法也有它的缺點(diǎn)，但在以下幾點(diǎn)中會(huì)詳細(xì)說(shuō)明這一點(diǎn)。
同時(shí)，gRPC只支持兩種數(shù)據(jù)交換格式：
①Protobuf —默認(rèn)情況下。
②JSON—當(dāng)需要與原有API集成時(shí)。
如果用戶(hù)嘗試使用JSON，那么gRPC將使用JSON作為消息的編碼格式，而使用GSON作為消息格式。此外，使用JSON需要做更多的配置。
（3）數(shù)據(jù)大小
默認(rèn)情況下，gRPC使用二進(jìn)制數(shù)據(jù)交換格式，這顯著地減少了通過(guò)網(wǎng)絡(luò)發(fā)送的消息的大?。貉芯勘砻?，以字節(jié)計(jì)算，大約減少了40%～50%，而從以前的一個(gè)項(xiàng)目中獲得的經(jīng)驗(yàn)表明，甚至減少了50%～70%。
以上提供了JSON和Protobuff之間相對(duì)深入的大小比較。本文作者還提供了一個(gè)生成JSON和二進(jìn)制文件的工具。這樣就可以重新運(yùn)行他的實(shí)驗(yàn)并比較結(jié)果。
本文中的對(duì)象相當(dāng)簡(jiǎn)單。不過(guò)，一般的規(guī)則是——嵌入的對(duì)象越多，JSON的結(jié)構(gòu)越復(fù)雜，它就會(huì)比Protobuf更重。50%的大小差異有利于Protobuf 是一個(gè)很好的基線。
在使用REST的二進(jìn)制交換格式時(shí)，可以最大限度地減少或消除這種差異。然而，這不是最常見(jiàn)的，也不是最受支持的RESTful API方式，因此可能會(huì)出現(xiàn)其他問(wèn)題。
（4）吞吐量
同樣，在REST的情況下，一切都取決于底層HTTP協(xié)議和服務(wù)器。
在默認(rèn)情況下，基于HTTP/1.1的REST，即使是最高性能的服務(wù)器也無(wú)法擊敗gRPC的性能，特別是當(dāng)使用JSON時(shí)添加序列化和反序列化開(kāi)銷(xiāo)時(shí)。雖然當(dāng)切換到HTTP/2時(shí)，差異似乎有所減少。
至于最大吞吐量，在這兩種情況下，HTTP都是一種傳輸媒介，因此它具有無(wú)限擴(kuò)展的潛力。因此，一切都取決于正在使用的工具以及對(duì)應(yīng)用程序的精確操作，因?yàn)樵O(shè)計(jì)沒(méi)有限制。
（5）定義
在這一部分中，將描述如何在這兩種方法中定義消息和服務(wù)。
在大多數(shù)REST應(yīng)用程序中，只是將請(qǐng)求和響應(yīng)聲明為類(lèi)、對(duì)象或特定語(yǔ)言支持的任何結(jié)構(gòu)。然后，依靠提供的庫(kù)來(lái)序列化和反序列化JSON/XML/YAML或任何需要的格式。
此外，目前正在努力創(chuàng)建能夠根據(jù)Swagger的REST API定義用所選編程語(yǔ)言生成代碼的工具。然而，它們似乎是在alpha版本中，所以仍然可能會(huì)出現(xiàn)一些錯(cuò)誤和小問(wèn)題，這將使它們難以使用。
REST應(yīng)用程序的二進(jìn)制格式和非二進(jìn)制格式之間幾乎沒(méi)有區(qū)別，因?yàn)檫@兩種情況下的規(guī)則大致相同。對(duì)于二進(jìn)制格式，只是以特定格式所需的方式定義所有內(nèi)容。
此外，可以通過(guò)來(lái)自底層庫(kù)或框架的方法或注釋來(lái)定義REST服務(wù)。該工具還負(fù)責(zé)將其與其他配置一起向外部世界公開(kāi)。
在gRPC的情況下，將Protobuf作為默認(rèn)的并且事實(shí)上是編寫(xiě)定義的唯一方式。必須在.proto文件中聲明所有內(nèi)容：消息、服務(wù)和方法，所以事情非常簡(jiǎn)單。
然后使用gRPC提供的工具生成代碼，只需要實(shí)現(xiàn)自己的方法。在那之后，一切都應(yīng)該按預(yù)期工作。
此外，Protobuf支持導(dǎo)入，因此能夠以一種相當(dāng)簡(jiǎn)單的方式將設(shè)置擴(kuò)展到多個(gè)文件。
（6）易于采用
在這一部分中，將比較現(xiàn)代編程語(yǔ)言中對(duì)每種方法的庫(kù)/框架支持。
本文作者表示，在他作為軟件工程師的職業(yè)生涯中，遇到的每種編程語(yǔ)言(Java、Scala、Python)都至少有3個(gè)主要的庫(kù)/框架用于創(chuàng)建類(lèi)REST應(yīng)用程序，更不用說(shuō)將JSON解析為對(duì)象/類(lèi)的庫(kù)了。
此外，由于REST默認(rèn)使用人類(lèi)可讀的格式，因此對(duì)于新手來(lái)說(shuō)，它更容易調(diào)試和使用。這也會(huì)影響交付新特性的速度，并幫助用戶(hù)應(yīng)對(duì)代碼中出現(xiàn)的錯(cuò)誤。
長(zhǎng)話(huà)短說(shuō)，對(duì)REST風(fēng)格應(yīng)用程序的支持至少非常好。
在Scala中，甚至有一個(gè)叫做Tapir的工具。Tapir允許用戶(hù)抽象HTTP服務(wù)器，并編寫(xiě)可用于多個(gè)服務(wù)器的端點(diǎn)。
gRPC本身為超過(guò)8種流行的編程語(yǔ)言提供了客戶(hù)端庫(kù)。這通常就足夠了，因?yàn)檫@些庫(kù)包含了制作gRPC API所需的所有內(nèi)容。此外，一些庫(kù)為Java(通過(guò)Spring Boot Starter)和Scala提供了更高的抽象。
另一件事是，REST如今被認(rèn)為是一個(gè)世界性的標(biāo)準(zhǔn)和構(gòu)建服務(wù)的切入點(diǎn)，而RPC和gRPC，特別是，盡管在這一點(diǎn)上有點(diǎn)過(guò)時(shí)，但仍然被視為一種新奇事物。
（7）工具支持
以上已經(jīng)介紹了庫(kù)、框架和一般市場(chǎng)份額，所以在這一部分中介紹圍繞這兩種風(fēng)格的工具。它意味著用于測(cè)試、性能/壓力測(cè)試和文檔的工具。
①自動(dòng)化測(cè)試
首先，在REST的情況下，用于構(gòu)建自動(dòng)化測(cè)試的工具被構(gòu)建到不同的庫(kù)和框架中，或者是為了這個(gè)唯一目的而構(gòu)建的獨(dú)立工具，比如REST-assured。
在gRPC的情況下，可以生成一個(gè)stub并將其用于測(cè)試。如果想要更嚴(yán)格，可以將生成的客戶(hù)端作為一個(gè)單獨(dú)的應(yīng)用程序使用，并將其用作對(duì)實(shí)際服務(wù)進(jìn)行測(cè)試的基礎(chǔ)。
關(guān)于gRPC的外部工具支持，需要知道：
②性能測(cè)試
在這里，REST具有顯著的優(yōu)勢(shì)，因?yàn)橄馢Meter或Gatling這樣的工具使REST API的壓力測(cè)試變得相當(dāng)容易。
不幸的是，gRPC沒(méi)有這樣的支持。在當(dāng)前的Gatling版本中包含了gRPC插件，所以情況似乎正在好轉(zhuǎn)。
然而到目前為止，只有一個(gè)名為ghz的非官方插件和庫(kù)。這些都很好；它只是與REST的支持級(jí)別不同。
③文檔
在API文檔方面，隨著OpenAPI和Swagger在整個(gè)行業(yè)被廣泛采用并成為事實(shí)上的標(biāo)準(zhǔn)，REST再次取得了勝利。幾乎所有用于REST的庫(kù)都能夠以最小的努力或開(kāi)箱即用的方式公開(kāi)Swagger文檔。
不幸的是，gRPC沒(méi)有這樣的文檔。
然而，問(wèn)題是gRPC是否需要這樣的工具。gRPC在設(shè)計(jì)上比REST更具描述性，因此可能需要其他文檔工具。
一般來(lái)說(shuō)，帶有API描述的.proto文件比負(fù)責(zé)編寫(xiě)REST API代碼的代碼更具聲明性和緊湊性，因此可能不需要gRPC提供更多文檔。
④總體結(jié)果
這是REST的一次重大勝利。
以下是gRPC和REST比較的最終得分表。
得出的結(jié)論是：gRPC和REST的比較結(jié)果平分秋色，各有三場(chǎng)勝利，沒(méi)有明顯的贏家。
因此沒(méi)有什么靈丹妙藥，用戶(hù)只需要考慮哪些類(lèi)別可能對(duì)應(yīng)用程序最重要，然后選擇在大多數(shù)類(lèi)別中獲勝的方法。
本文作者表示，如果可以的話(huà)，他會(huì)嘗試使用gRPC，因?yàn)間RPC在他的上一個(gè)項(xiàng)目中運(yùn)行得非常好。它可能是比原有的REST更好的選擇。
原文標(biāo)題：gRPC vs REST：Comparing Approaches for Making APIs，作者：Bart?omiej ?yliński
本文鏈接：http://www.tebozhan.com/showinfo-26-5710-0.htmlgRPC?vs?REST：創(chuàng)建API的方法比較
聲明：本網(wǎng)頁(yè)內(nèi)容旨在傳播知識(shí)，若有侵權(quán)等問(wèn)題請(qǐng)及時(shí)與本網(wǎng)聯(lián)系，我們將在第一時(shí)間刪除處理。郵件：2376512515@qq.com
Copyright ? 2016-2023 天津谷騏科技有限公司 版權(quán)所有 sitemap.xml
違法及侵權(quán)請(qǐng)聯(lián)系：2376512515@qq.com 津ICP備18001702號(hào)
津公網(wǎng)安備 12010102000574號(hào)