何時使用GraphQL、gRPC 和 REST

何時使用GraphQL、gRPC 和 REST

       在設計應用程序時，開發人員可以從各種客戶端-服務器通信協議中進行選擇。使用 GraphQL、gRPC 和 REST 在當代項目中相對常見。每種協議都可以提供各種優勢，具體取決於您的應用需求。

       一.GraphQL 是一種靈活的數據請求方法，它專注於特定請求並僅提供必要的請求。GraphQL 是客戶端驅動的，這一事實將其與其他 API 區分開來，而不是以標準方式處理它，由客戶端做出所有決策。它的優點是它與語言無關，請求是通過單個終結點發出的，並且是強類型的，因爲它具有架構。

     GraphQL 的優點和缺點
GraphQL 讓開發人員能夠專注於他們的查詢，只提取他們想要的數據。

雖然這種靈活性對客戶端來說是一個好處，但對服務器開發人員來說也是一個缺點。需要有人做繁重的工作，這樣服務器性能才能不可預測。請求的完全自定義也意味着緩存非常困難。對於希望採用 GraphQL 方法的 API 開發人員來說，這些困難確實轉化爲陡峭的學習曲線。

      何時使用 GraphQL
如果您預計客戶端會以多種方式使用您的數據，那麼 GraphQL 可能是一個理想的選擇。賦予 API 使用者權力可能意味着在後端做更多的工作，但它可能會使您的 API 更易於使用。假設客戶端應用程序需要高度結構化的信息來構建界面或填充應用程序中顯示的信息。在這種情況下，GraphQL 可以成爲減少您需要向服務器發出的請求數量的好方法。

      二. REST是最受歡迎的一種。當一個域可以被描述爲一組資源時，它非常適合。REST是一種用於數據傳輸的無狀態架構。REST的一些優點是它是一個成熟的標準，使用簡單，並且具有良好的緩存支持。

REST 的優缺點
什麼是 RESTful API？它們被廣泛使用，大多數應用程序開發人員都熟悉它們。由於 REST 與 HTTP 協議的設計密切相關，因此瀏覽器和其他 HTTP 客戶端將原生理解來自 RESTful API 的響應。

不過，REST並不是萬能的，這就是爲什麼它不是唯一的API架構。RESTful API 可能會導致臃腫的響應，尤其是在資源特別複雜的情況下，這是 GraphQL 日益普及的驅動因素之一。對於功耗非常低的客戶端來說，REST 也可能不是一個理想的選擇，這就是 gRPC 在這種情況下的吸引力所在。

RESTful API 開發的靈活性也讓開發人員承擔了遵守原則和標準的責任。雖然 OpenAPI 規範是一個很好的工具，但堅持它必須是一個積極的決定，因爲 RESTful API 本質上並不是自文檔化的。

POST：創建新資源。
PUT：如果資源存在，則完全更新資源，如果不存在，則創建資源。
DELETE：刪除資源。
PATCH：部分更新現有資源。
GET：查詢一個或多個現有資源。

     何時使用 REST API
如果您沒有令人信服的理由選擇其他方式，那麼 REST 可能是您的應用程序的最佳選擇。雖然 GraphQL 或 gRPC 可能適合具有獨特需求的用例，但更多時候，您只想使用良好、可靠的 API 方法進行構建。由於 REST API 的學習曲線較淺，擁有龐大的資源生態系統和大量可供學習的公開示例，因此應將 REST API 視爲默認選擇。

     三. gRPC 是一種提供輕量級和快速系統來獲取數據的方法。在這裏，主要區別在於它如何描述其合同談判。它依賴於合同;架構不是管理談判的東西;它是服務器和客戶端之間的關係。雖然處理和計算被委託給容納資源的遠程服務器，但大部分都在客戶端使用。它的主要優點是它具有輕量級客戶端，使用協議緩衝區發送/接收數據時效率很高，並且是開源的。gRPC 是更通用的遠程過程調用概念的演變設計。它允許客戶端直接調用遠程計算機上的方法，就好像該系統是本地的一樣。gRPC 利用協議緩衝區（或 Protobufs）來定義類型安全的接口，並將數據序列化爲二進制（而不是基於文本的 JSON 或 XML）以進行數據傳輸。它還利用了 HTTP/2 的速度和效率，它比 HTTP/1 更可靠、更快。

    gRPC 的優點和缺點
      使用 Protobufs 進行數據序列化，gRPC 提供了一個令人難以置信的輕量級和快速的 API。由於它非常輕量級，因此在客戶端可能沒有太多計算能力（例如 IoT）時，通常會使用 gRPC。在這些情況下，服務器會執行繁重的工作。gRPC 還提供了一種在用不同語言編寫的服務之間進行通信的絕佳方式，因爲接口協定的定義與語言無關。這使得 gRPC 的學習曲線（雖然不像 REST 那麼淺）是可以容忍的。雖然 gRPC 非常高效，但瀏覽器並未很好地支持它。通過在沙盒中進行實驗來學習也可能很困難。對於經驗不足的 API 開發人員來說，HTTP/2 的使用也可能不熟悉。

     何時使用 gRPC
如果需要從客戶端計算機中榨取每一滴性能，gRPC 可能是一個不錯的選擇。這就是爲什麼 gRPC 的一個廣泛用例是促進智能設備之間的通信。鑑於其規模、有限的計算資源和實時功能，物聯網設備依賴於 gRPC 的性能才能運行。部署管道工具和應用程序監視系統也可以是 gRPC 的出色應用程序。

因此，何時選擇這些協議中的每一個：

  如果要構建 CRUD 樣式的 Web 應用程序，或者使用結構良好的數據，請使用 REST。

  如果 API 是私有的，並且與操作有關，請使用 gRPC。此外，如果性能是必不可少的。

  如果您是公共 API，需要靈活地自定義請求，並且希望將來自不同來源的數據添加到公共 API 中，請使用 GraphQL。

我們演示瞭如何在不同的應用層中應用不同的 API 樣式:

結論
      我們已經看到，沒有一種放之四海而皆準的 API 開發方法。微服務允許獨立於其他系統對應用程序功能進行抽象、增強和修改。如果系統的一部分需要 gRPC 實現，其他部分可以合理地同時使用 GraphQL API，同時使用 REST 設計公開其他內容。如您所見，這些選擇中的每一個都有特定的用途和好處。在這種情況下，沒有明確的贏家，所以你應該使用什麼——或者更確切地說，你想使用什麼——取決於你的目標和策略。

--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

微服務架構設計
視頻直播平臺的系統架構演化
微服務與Docker介紹
Docker與CI持續集成/CD
互聯網電商購物車架構演變案例
互聯網業務場景下消息隊列架構
互聯網高效研發團隊管理演進之一
消息系統架構設計演進
互聯網電商搜索架構演化之一
企業信息化與軟件工程的迷思
企業項目化管理介紹
軟件項目成功之要素
人際溝通風格介紹一
精益IT組織與分享式領導
學習型組織與企業
企業創新文化與等級觀念
組織目標與個人目標
初創公司人才招聘與管理
人才公司環境與企業文化
企業文化、團隊文化與知識共享
高效能的團隊建設
項目管理溝通計劃
構建高效的研發與自動化運維
某大型電商雲平臺實踐
互聯網數據庫架構設計思路
IT基礎架構規劃方案一(網絡系統規劃)
餐飲行業解決方案之客戶分析流程
餐飲行業解決方案之採購戰略制定與實施流程
餐飲行業解決方案之業務設計流程
供應鏈需求調研CheckList
企業應用之性能實時度量系統演變

如有想了解更多軟件設計與架構, 系統IT,企業信息化, 團隊管理 資訊，請關注我的微信訂閱號：

作者：Petter Liu
出處：http://www.cnblogs.com/wintersun/
本文版權歸作者和博客園共有，歡迎轉載，但未經作者同意必須保留此段聲明，且在文章頁面明顯位置給出原文連接，否則保留追究法律責任的權利。 該文章也同時發佈在我的獨立博客中-Petter Liu Blog。