REST 和 gRPC 構(gòu)建 WEB API 詳細(xì)比較
當(dāng)前位置：點晴教程→知識管理交流
→『 技術(shù)文檔交流 』
導(dǎo)讀 譯者注：在微服務(wù)架構(gòu)設(shè)計，構(gòu)建API和服務(wù)間通信技術(shù)選型時，對 REST 和 gRPC 的理解和應(yīng)用還存在知識盲區(qū)，近期看到國外的這篇文章：A detailed comparison of REST and gRPC[1]，將二者進(jìn)行了詳細(xì)對比。周末有時間翻譯過來，希望能幫到大家！ 很長一段時間以來，REST是構(gòu)建API的唯一“標(biāo)準(zhǔn)”。近年來，出現(xiàn)了新的替代方案。2015年，臉書發(fā)布了GraphQL，2016年谷歌緊隨其后發(fā)布了gRPC，被廣泛使用。在本文中，將關(guān)注gRPC，并將其與REST進(jìn)行比較。 概述下表將概述本文討論的要點，并顯示 REST 和 gRPC 真正的亮點。
標(biāo)準(zhǔn)化REST 缺點之一是缺乏標(biāo)準(zhǔn)化，與其說 REST 是一個API標(biāo)準(zhǔn)，不如說是一種范式。許多人在談?wù)撍鼤r都有不同的含義。對大多數(shù)人來說，術(shù)語“REST API”是基于HTTP的JSON API；對于其他規(guī)范，REST 可以與某些規(guī)范（如：HATEOAS[2]或 JSON:API[3]）互換使用。 REST這個術(shù)語甚至與HTTP無關(guān)。在使用 REST API 時，可能會導(dǎo)致很多混亂。例如，即使沒有明確定義，使用者可能會期望某些 REST API 端點的冪等性或可緩存性。 相比之下，gRPC定義得很好。例如，基于 HTTP/2 的gRPC實現(xiàn)非常詳細(xì)。 基本差異REST 和 gRPC 的范式并不相同。 REST 一切都以資源為中心，這些資源可以被檢索和操作。如果以圖書作為示例資源，REST API通常會提供以下端點：
大多數(shù)基于 HTTP 的 REST API 都遵循這種模式。這很好，但某些情況很難表示為 REST API。例如，如果想創(chuàng)建多本書，而不想為每本書重復(fù)調(diào)用 另一方面，gRPC是一個RPC框架，以服務(wù)方法為中心。如果以圖書 API為例，使用gRPC，將使用以下方法創(chuàng)建
可以隨心所欲地命名這些方法，并設(shè)置任何需要的參數(shù)。如果現(xiàn)在想添加一個方法來創(chuàng)建多本書，沒有什么能阻止我們添加 服務(wù)模式gRPC 支持四種服務(wù)方法：
與只支持一元請求的 REST 相比，gRPC 有一個非常好的優(yōu)勢。在 REST API 中支持其他服務(wù)模式需要使用不同的協(xié)議，例如：服務(wù)器發(fā)送的事件或 要求REST API通常“只適用于”任何類型的 HTTP 版本。只要一種編程語言有一個 HTTP 客戶端和一個用于 JSON 解析的庫，那么使用 REST API 就輕而易舉了。 gRPC 明確需要 HTTP/2 支持，否則它將無法工作。近年來，由于大多數(shù)框架都增加了對 HTTP/2 的支持，這已經(jīng)不再是一個問題了。 由于 gRPC 需要生成代碼（用于創(chuàng)建客戶端或服務(wù)器存根），因此僅部分編程語言支持，查看編程語言列表[4]。 API 設(shè)計REST API 通常是其實現(xiàn)的結(jié)果，稱為“代碼優(yōu)先（code-first）”。雖然可以先用 OpenAPI 設(shè)計API，然后生成服務(wù)器存根，但這不是許多開發(fā)人員采用的方法。如果有一個 OpenAPI 定義，那么 OpenAPI 定義很可能是從 API 實現(xiàn)生成的。因此，API定義與實現(xiàn)緊密耦合。模型類的更改可能會導(dǎo)致 API 更改，無意中破壞接口規(guī)范。 gRPC 使用不同的方法，在實現(xiàn)API之前必須定義API（稱為“設(shè)計優(yōu)先（design-first）”）。然后根據(jù) API 定義生成客戶端和服務(wù)器存根。這需要提前考慮，因為不能直接實現(xiàn)API。 兩種方法各有利弊。通常 REST API 方法允許快速迭代；使用gRPC，在調(diào)整 API 實現(xiàn)之前首先更改 API 定義，這可能會很煩人。然而，通過顯式定義API更加安全，API變動沒那么隨意。 數(shù)據(jù)格式REST 和 gRPC 都可以使用不同的格式來傳輸數(shù)據(jù)。大多數(shù) REST API 使用JSON，而 gRPC 默認(rèn)使用 Protocol Buffers[5]，一種輕便高效的結(jié)構(gòu)化數(shù)據(jù)存儲格式，因此我們將比較這兩者。 JSON 對數(shù)據(jù)類型的支持有限，例如，大數(shù)字需要表示為字符串。JOSON 是一種文本格式，便于閱讀。字段名序列化會占用一些空間。在一些編程語言中，還需要使用反射來反序列化 JSON 消息，速度慢。 如上所述，gRPC API 和相應(yīng)的消息類型首先被定義為 Protocol Buffers 。每條消息都是強(qiáng)類型的，對于支持的編程語言，可以自動生成代碼以（反）序列化消息。由于它是一種二進(jìn)制格式，并且不序列化字段名，因此它使用的空間比等效的JSON消息少。但是存在缺點：即序列化消息不可讀，并且需要 Protobuf 定義來反序列化消息，可能會影響開發(fā)人員的體驗。 下面的 JSON 示例將占用大約66個字節(jié)（去掉空白）。 等效的序列化 protobuf 消息將僅使用19個字節(jié)。 0x0A070A034D617810170A080A0448616E731034 大消息Protobuf 設(shè)計用于序列化和反序列化內(nèi)存中的消息。因此，不建議使用 Protobuf/gRPC 傳輸巨大的消息。大多數(shù) gRPC 實現(xiàn)對單個消息的默認(rèn)限制為 使用 REST API 處理大數(shù)據(jù)量（例如文件上傳）是相當(dāng)直接的。接收到的文件可以被視為流，只需使用很少的內(nèi)存。這在 gRPC 中需要更多的操作：文件必須在發(fā)送方分為幾個部分。然后，每個塊將作為單獨的消息通過客戶端流傳輸方法發(fā)送到服務(wù)器。服務(wù)器接收每個塊，并構(gòu)造數(shù)據(jù)流，從而產(chǎn)生與 REST API 類似的行為。 瀏覽器兼容性瀏覽器兼容是 REST 真正的閃光點。它由 WEB 瀏覽器本地支持，因此可以輕松地使用 WEB應(yīng)用程序中的 REST API。 gRPC 不直接由瀏覽器支持，因為它需要明確的 HTTP/2 支持和訪問某些 HTTP/2 功能，而 WEB瀏覽器不提供這些功能。作為一種變通方法，可以使用 gRPC Web 協(xié)議，使其可供 WEB 瀏覽器使用。對于某些編程語言，框架中已經(jīng)包含了gRPC Web 支持。對于其他場景，需要一個代理來將 gRPC 流轉(zhuǎn)換為 gRPC Web 流，反之亦然。與不需要依賴關(guān)系的 REST API 相比，gRPC API 在 WEB 上使用更麻煩。 解決方法可以是使用 JSON 轉(zhuǎn)碼，這允許開發(fā)人員將 gRPC API 公開為 REST API。 工具gRPC 和 REST 工具在編程語言和框架之間差異很大。在某些情況下，gRPC 感覺更“原生”，而在另一些情況下，REST 工具則更高級。 對 gRPC 的編程語言支持更為重要，因為需要工具來生成特定編程語言的客戶端和服務(wù)器存根。對于不受支持的編程語言，不建議使用 gRPC 。 由于 REST API 存在的時間要長得多，因此存在更多有助于構(gòu)建、測試和部署 REST API 的工具。它們的功能通常比 gRPC 工具更高級。 小結(jié)對于“應(yīng)該使用 REST 還是 gRPC ？” 沒有明確的答案。有些 API 有獨特的用例，gRPC 或 REST 可能更適合這些用例。 REST 和 gRPC 都有各自的優(yōu)點和缺點。 從 WEB 應(yīng)用程序中使用 REST API 通常更容易。REST也得到了更廣泛的使用，這使得開發(fā)人員使用它更簡單。 gRPC 在服務(wù)器到服務(wù)器的通信（例如：微服務(wù)之間）方面無疑具有優(yōu)勢。能夠共享準(zhǔn)確的API定義并用多種編程語言創(chuàng)建 API 客戶端，這是一個巨大的優(yōu)勢。 引用鏈接
該文章在 2023/6/14 9:39:37 編輯過 |
關(guān)鍵字查詢
相關(guān)文章
正在查詢... 
|
400 186 1886
