狠狠色丁香婷婷综合尤物/久久精品综合一区二区三区/中国有色金属学报/国产日韩欧美在线观看 - 国产一区二区三区四区五区tv

很長一段時間以來，REST是構建API的唯一“標準”。近年來，出現了新的替代方案。2015年，臉書發布了GraphQL，2016年谷歌緊隨其后發布了gRPC，被廣泛使用。在本文中，將關注gRPC，并將其與REST進行比較。

概述

下表將概述本文討論的要點，并顯示 REST 和 gRPC 真正的亮點。

標準化

REST 缺點之一是缺乏標準化，與其說 REST 是一個API標準，不如說是一種范式。許多人在談論它時都有不同的含義。對大多數人來說，術語“REST API”是基于HTTP的JSON API；對于其他規范，REST 可以與某些規范（如：HATEOAS^[2]或 JSON:API^[3]）互換使用。

REST這個術語甚至與HTTP無關。在使用 REST API 時，可能會導致很多混亂。例如，即使沒有明確定義，使用者可能會期望某些 REST API 端點的冪等性或可緩存性。

相比之下，gRPC定義得很好。例如，基于 HTTP/2 的gRPC實現非常詳細。

基本差異

REST 和 gRPC 的范式并不相同。

REST 一切都以資源為中心，這些資源可以被檢索和操作。如果以圖書作為示例資源，REST API通常會提供以下端點：

• • GET /books ：檢索所有書，可帶有篩選和分頁結果的參數

• • GET /books/{id} ：檢索指定ID書

• • POST /books ：創建書

• • delete /books/{id} ：刪除書

大多數基于 HTTP 的 REST API 都遵循這種模式。這很好，但某些情況很難表示為 REST API。例如，如果想創建多本書，而不想為每本書重復調用 POST/books（出于性能、冪等性或其他原因），該怎么辦？是否應該創建 POST/books/batch 端點？這還是“RESTful”嗎？雖然在技術上容易解決，但開發人員之間經常會進行長時間的討論。

另一方面，gRPC是一個RPC框架，以服務方法為中心。如果以圖書 API為例，使用gRPC，將使用以下方法創建 BookService ：

• • GetBooks()

• • GetBook()

• • createBook()

• • deleteBook()

可以隨心所欲地命名這些方法，并設置任何需要的參數。如果現在想添加一個方法來創建多本書，沒有什么能阻止我們添加 createBooks() 方法。gRPC 在設計 API 時提供了更多的“自由”，因為有更少的（自我強加的）限制。

服務模式

gRPC 支持四種服務方法：

• • 一元流：發送單個請求，接收單個響應。

• • 服務器流：發送單一請求，接收多個響應。

• • 客戶端流：發送多個請求，接收單一響應。

• • 雙向流：發送多個請求，接收多個響應。

與只支持一元請求的 REST 相比，gRPC 有一個非常好的優勢。在 REST API 中支持其他服務模式需要使用不同的協議，例如：服務器發送的事件或websocket，這不是很“RESTful”。

要求

REST API通常“只適用于”任何類型的 HTTP 版本。只要一種編程語言有一個 HTTP 客戶端和一個用于 JSON 解析的庫，那么使用 REST API 就輕而易舉了。

gRPC 明確需要 HTTP/2 支持，否則它將無法工作。近年來，由于大多數框架都增加了對 HTTP/2 的支持，這已經不再是一個問題了。

由于 gRPC 需要生成代碼（用于創建客戶端或服務器存根），因此僅部分編程語言支持，查看編程語言列表^[4]。

API 設計

REST API 通常是其實現的結果，稱為“代碼優先（code-first）”。雖然可以先用 OpenAPI 設計API，然后生成服務器存根，但這不是許多開發人員采用的方法。如果有一個 OpenAPI 定義，那么 OpenAPI 定義很可能是從 API 實現生成的。因此，API定義與實現緊密耦合。模型類的更改可能會導致 API 更改，無意中破壞接口規范。

gRPC 使用不同的方法，在實現API之前必須定義API（稱為“設計優先（design-first）”）。然后根據 API 定義生成客戶端和服務器存根。這需要提前考慮，因為不能直接實現API。

兩種方法各有利弊。通常 REST API 方法允許快速迭代；使用gRPC，在調整 API 實現之前首先更改 API 定義，這可能會很煩人。然而，通過顯式定義API更加安全，API變動沒那么隨意。

數據格式

REST 和 gRPC 都可以使用不同的格式來傳輸數據。大多數 REST API 使用JSON，而 gRPC 默認使用 Protocol Buffers^[5]，一種輕便高效的結構化數據存儲格式，因此我們將比較這兩者。

JSON 對數據類型的支持有限，例如，大數字需要表示為字符串。JOSON 是一種文本格式，便于閱讀。字段名序列化會占用一些空間。在一些編程語言中，還需要使用反射來反序列化 JSON 消息，速度慢。

如上所述，gRPC API 和相應的消息類型首先被定義為 Protocol Buffers 。每條消息都是強類型的，對于支持的編程語言，可以自動生成代碼以（反）序列化消息。由于它是一種二進制格式，并且不序列化字段名，因此它使用的空間比等效的JSON消息少。但是存在缺點：即序列化消息不可讀，并且需要 Protobuf 定義來反序列化消息，可能會影響開發人員的體驗。

下面的 JSON 示例將占用大約66個字節（去掉空白）。

{
  "persons": [
    {
      "name": "Max",
      "age": 23
    },
    {
      "name": "Mike",
      "age": 52
    }
  ]
}

等效的序列化 protobuf 消息將僅使用19個字節。

0x0A070A034D617810170A080A0448616E731034

大消息

Protobuf 設計用于序列化和反序列化內存中的消息。因此，不建議使用 Protobuf/gRPC 傳輸巨大的消息。大多數 gRPC 實現對單個消息的默認限制為4MB。

使用 REST API 處理大數據量（例如文件上傳）是相當直接的。接收到的文件可以被視為流，只需使用很少的內存。這在 gRPC 中需要更多的操作：文件必須在發送方分為幾個部分。然后，每個塊將作為單獨的消息通過客戶端流傳輸方法發送到服務器。服務器接收每個塊，并構造數據流，從而產生與 REST API 類似的行為。

瀏覽器兼容性

瀏覽器兼容是 REST 真正的閃光點。它由 WEB 瀏覽器本地支持，因此可以輕松地使用 WEB應用程序中的 REST API。

gRPC 不直接由瀏覽器支持，因為它需要明確的 HTTP/2 支持和訪問某些 HTTP/2 功能，而 WEB瀏覽器不提供這些功能。作為一種變通方法，可以使用 gRPC Web 協議，使其可供 WEB 瀏覽器使用。對于某些編程語言，框架中已經包含了gRPC Web 支持。對于其他場景，需要一個代理來將 gRPC 流轉換為 gRPC Web 流，反之亦然。與不需要依賴關系的 REST API 相比，gRPC API 在 WEB 上使用更麻煩。

解決方法可以是使用 JSON 轉碼，這允許開發人員將 gRPC API 公開為 REST API。

工具

gRPC 和 REST 工具在編程語言和框架之間差異很大。在某些情況下，gRPC 感覺更“原生”，而在另一些情況下，REST 工具則更高級。 對 gRPC 的編程語言支持更為重要，因為需要工具來生成特定編程語言的客戶端和服務器存根。對于不受支持的編程語言，不建議使用 gRPC 。

由于 REST API 存在的時間要長得多，因此存在更多有助于構建、測試和部署 REST API 的工具。它們的功能通常比 gRPC 工具更高級。

小結

對于“應該使用 REST 還是 gRPC ？” 沒有明確的答案。有些 API 有獨特的用例，gRPC 或 REST 可能更適合這些用例。

REST 和 gRPC 都有各自的優點和缺點。

從 WEB 應用程序中使用 REST API 通常更容易。REST也得到了更廣泛的使用，這使得開發人員使用它更簡單。

gRPC 在服務器到服務器的通信（例如：微服務之間）方面無疑具有優勢。能夠共享準確的API定義并用多種編程語言創建 API 客戶端，這是一個巨大的優勢。

引用鏈接

[1] A detailed comparison of REST and gRPC: https://kreya.app/blog/rest-vs-grpc/
[2] HATEOAS: https://en.wikipedia.org/wiki/HATEOAS
[3] JSON:API: https://jsonapi.org/
[4] 編程語言列表: https://grpc.io/docs/languages/
[5] Protocol Buffers: https://protobuf.dev