揭露：這篇文章包含附屬連結；如果您透過本文中提供的不同連結購買產品或服務，我可能會獲得補償。
image_credit -設計大師
開發者們大家好，如果您正在準備編碼面試以及系統設計和微服務面試，您還應該準備 REST、GraphQL 和 gRPC 等內容，例如REST、GraphQL 和 gRPC 之間有什麼區別？ ，這也是程式設計面試的熱門議題之一。
之前，我討論了API 網關與負載平衡器、水平與垂直擴展、 正向代理與反向代理之間的區別以及JWT、OAuth 和 SAML 之間的區別，在本文中，我將分享我對REST、 GraphQL 的想法，和 gRPC，這三種用於建立 Web API 的流行通訊協定。
它們用於允許不同的軟體元件透過網路相互通信，例如微服務可以使用 REST 在它們之間進行同步通訊。
這些協議都有自己的優點和缺點，了解它們之間的差異不僅從技術面試的角度很重要，而且對於為您的專案選擇正確的協議也很重要。
在本文中，您將了解REST、GraphQL 和 gRPC 之間的差異。您將了解每個協議背後的核心概念、它們的優點和缺點，並提供一些何時使用每個協議的用例。
讀完本文後，您應該更了解哪種協議最適合您的專案要求。
順便說一句，如果您正在準備系統設計面試並想深入學習系統設計，那麼您還可以查看ByteByteGo 、 Design Guru 、 Exponent 、 Educative和Udemy等網站，它們有許多很棒的系統設計課程
我們將首先進行一些介紹，然後深入研究它們中的每一個，然後再次回顧它們的差異，以便您清楚地了解它們的優點和缺點以及何時使用它們。
REST代表表述性狀態傳輸，它是一種流行的協議，用於建立透過 HTTP 公開資料和功能的 Web 服務。
它基於 HTTP 協定和一組約束，定義如何辨識和定址資源以及如何對這些資源執行操作。
另一方面， GraphQL是 Facebook 開發的 API 查詢語言。它允許客戶端準確指定他們需要的資料，並且伺服器僅使用該資料進行回應。
GraphQL 的建立是為了解決 REST 的缺點和限制，因此它提供了一種更靈活、更有效的從伺服器獲取資料的方式，因為客戶端可以在單一請求中請求多個資源。
而且， gRPC是一種用於建立 API 的高效能開源協定。它使用Google 的 Protocol Buffers作為資料格式，並提供對串流和雙向通訊的支援。
gRPC 由於其效能和對多種程式語言的支援而經常用於微服務架構中。
現在我們知道它們是什麼，讓我們深入研究它們。
什麼是 REST？什麼時候使用它？
正如我所說，REST（表述性狀態傳輸）是一種用於設計分散式應用程式（尤其是基於 Web 的 API）的架構風格。
RESTful API使用 HTTP 方法（例如 GET、POST、PUT、DELETE）對 URL（統一資源定位器）辨識的資源執行 CRUD（建立、讀取、更新、刪除）操作。
如果您了解 HTTP，那麼您就了解 REST。
REST 還依賴無狀態的客戶端-伺服器架構，其中來自客戶端的每個請求都包含伺服器完成請求所需的所有訊息，而無需維護會話狀態。
以下是 REST 是不錯選擇的一些場景：
-
當您需要透過 API 公開資料和服務時，因為 REST 是一種流行且完善的協議，用於建立可供其他應用程式和服務輕鬆使用的 API。
-
當您需要支援多種平台和程式語言時，因為 REST 依賴標準 HTTP 方法和資料格式，因此它可以被多種程式語言和平台使用。
-
當您需要支援快取時，因為REST支援緩存，這可以提高效能並減少網路流量。
-
當您需要建立簡單、輕量級的 API 時
-
當您需要支援大量資源時
此外，了解 HTTP 方法對於設計 REST API 非常重要。您可以進一步查看REST API 設計、開發和管理課程，以了解 REST API 設計、開發和管理。
總體而言， REST 是一種靈活且廣泛採用的協議，對於許多類型的 API 來說都是不錯的選擇。
然而，它可能不是所有場景的最佳選擇，特別是那些需要即時更新或更複雜的查詢和資料操作的場景。
在這些情況下，其他協定（例如 GraphQL 或 gRPC）可能更合適。
什麼是 GraphQL？什麼時候使用它？
GraphQL 是一種 API 查詢語言，由 Facebook 於 2012 年開發，並於 2015 年作為開源專案發布。
GraphQL 允許客戶端定義他們所需的資料結構，並且伺服器可以準確地回應該資料，而無需任何不必要的資料。
它通常用作 RESTful API 的替代方案，特別是在客戶端需要對傳回的資料進行細微控制的情況下。
以下是 GraphQL 是不錯選擇的一些場景：
-
當您想要減少網路流量時，GraphQL 允許客戶端準確指定他們需要的資料，這可以減少透過網路傳輸的不必要的資料量。
-
當您需要支援各種客戶端時，因為 GraphQL 支援強類型查詢，這可用於確保客戶端以他們理解的格式接收正確的資料。
-
當您需要支援即時更新時，因為 GraphQL 支援透過訂閱進行即時更新，這允許客戶端在更新可用時立即接收更新。
-
當您需要支援複雜的查詢和資料操作時：因為GraphQL允許客戶端使用簡單的語法執行複雜的查詢和資料操作操作，例如過濾、排序和聚合。
-
當您需要支援版本控制時，因為 GraphQL 透過允許客戶端指定他們在請求中使用的架構版本來支援版本控制，這樣隨著架構隨時間的發展，可以更輕鬆地保持向後相容性。
總的來說，GraphQL 是一個強大且靈活的協議，對於資料細粒度控制和即時更新很重要的場景來說，它是一個不錯的選擇。
但是，它可能比 RESTful API 需要更多的設定和配置，特別是當您使用多種程式語言或平台時。
您可以進一步查看GraphQL by Example和GraphQL with React: The Complete Developers Guide以了解有關 GraphQL 及其使用方法的更多資訊。
這也是一個很好的圖表，突出顯示了REST 和 GraphQL 查詢之間的差異：
什麼是 gRPC？什麼時候使用它？
現在讓我們看看什麼是 gRPC 以及它提供什麼？ gRPC 是 Google 開發的一個高效能、開源的遠端過程呼叫 (RPC) 框架。
它使用Protocol Buffers作為介面描述語言，支援多種程式語言，可以輕鬆建構跨不同平台和環境的分散式系統。
以下是 gRPC 是不錯選擇的一些場景：
-
當您需要高效能和高效率時，因為 gRPC 使用二進位協定並支援串流傳輸，這可以使其比其他協定更快、更有效率，特別是在高延遲或低頻寬連線上。
-
當您需要支援多種程式語言時，因為 gRPC 支援多種程式語言，包括 Java、C++、Python 和 Go，可以輕鬆建立跨不同平台和環境的分散式系統。
-
當您需要支援即時更新時，因為 gRPC 支援雙向流，這允許伺服器即時向客戶端發送更新。
-
當您需要處理大量資料時，因為 gRPC 使用 Protocol Buffers，它比 JSON 或 XML 等其他資料格式更有效率、更緊湊，使其成為處理大量資料的不錯選擇。
-
當您需要建立微服務或分散式系統時，因為 gRPC 提供了一個強大且靈活的框架，用於建立可以水平擴展並處理大量流量的微服務和分散式系統。
總體而言，gRPC 是一個強大且高效的協議，對於效能、效率和即時更新很重要的場景來說，它是一個不錯的選擇。
但是，與 RESTful API 等其他協定相比，它可能需要更多的設定和配置，特別是當您使用多種程式語言或平台時。
您可以進一步查看Protocol Buffers 3 完整指南 [Java、Golang、Python]和gRPC [Java] 大師班：建立現代 API 和微服務，以了解有關 gRPC 和 Google Protocol buffer 的更多資訊。
這是一個很好的圖表，突出顯示了 REST、gRPC 和 GraphQL 請求之間的區別
image_credit --- https://medium.com/@LadyNoBug/grpc-vs-rest-vs-others-5d8b6eaa61df
GraphQL、REST 和 gRPC 之間的區別
現在您已經了解什麼是REST、gRPC 和GraphQL 以及它們的工作原理，以下是REST、GraphQL 和gRPC 之間的主要區別（以點格式表示），記住它們的主要特徵以及何時在專案中使用它們：
REST：
-
代表代表性狀態轉移
-
使用 HTTP 方法（GET、POST、PUT、DELETE）執行 CRUD 操作
-
以結構化格式傳送資料，通常是 JSON 或 XML
-
不同資源可以有多個端點
-
客戶端收到回應中指定的所有資料，即使他們不需要全部資料
-
支援緩存，但管理起來可能很複雜
-
完善且廣泛採用，提供大量工具和文件
圖形語言：
-
允許客戶準確指定他們需要什麼資料，並僅接收該資料
-
使用單一端點存取多個資源
-
擁有自己的查詢語言，允許複雜的資料取得和操作
-
可以支援透過訂閱即時更新
-
在某些情況下比 REST 更有效率，特別是對於頻寬有限的行動設備
-
與 REST 相比，快取可以更細粒度且更易於管理
-
比 REST 需要更多的設定和配置，並且可能需要更多的專業知識才能有效使用
遠程過程呼叫：
-
代表帶有 Google 協定緩衝區的遠端程序呼叫 (RPC)
-
使用二進位資料代替 HTTP 進行通信
-
支援串流資料即時更新
-
使用協定緩衝區進行序列化，這比 JSON 或 XML 更有效率
-
可以跨不同的程式語言使用
-
專為微服務之間的高效能、低延遲通訊而設計
-
比 REST 需要更多的設定和配置，並且可能需要更多的專業知識才能有效使用
-
互通性可能不如 REST 或 GraphQL，因為它不是基於 HTTP
這裡還有一個很好的表格，突出顯示了 REST、GraphQL 和 gRPC 之間的區別，您可以使用它來快速複習：
還值得注意的是，這些協議並不相互排斥，並且可以組合使用它們以利用它們的不同優勢。
例如，您可能對大多數 API 使用 REST，但對某些資源密集型查詢使用 GraphQL，或使用 gRPC 在微服務之間進行通信，同時對外部 API 用戶端使用 REST 或 GraphQL。
系統設計訪談資源：
而且，如果您正在準備系統設計面試，那麼這裡有一些最佳系統設計書籍、線上課程和練習網站的精選列表，您可以查看這些內容，以便更好地準備系統設計面試。
-
DesignGuru 的 Grokking 系統設計課程：一個互動式學習平台，提供實作練習和真實場景，以增強您的系統設計技能。
-
《系統設計面試》作者：Alex Xu ：這本書深入探討了系統設計概念、策略和麵試準備技巧。
-
Martin Kleppmann 的「設計資料密集型應用程式」 ：綜合指南，涵蓋了設計可擴展且可靠的系統的原則和實踐。
-
LeetCode 系統設計 標籤：LeetCode 是一個受歡迎的技術面試準備平台。 LeetCode 上的系統設計標籤包含各種需要練習的問題。
-
GitHub 上的「系統設計入門」 ：精選的資源列表，包括文章、書籍和影片，可幫助您準備系統設計面試。
-
Educative 的系統設計課程：一個互動式學習平台，提供實作練習和真實場景，以增強您的系統設計技能。
-
高可擴展性部落格：該部落格包含有關高流量網站和可擴展系統架構的文章和案例研究。
-
YouTube 頻道：請參閱「Gaurav Sen」和「Tech Dummies」等頻道，以取得有關係統設計概念和麵試準備的富有洞察力的影片。
-
ByteByteGo ：Alex Xu 的一本現場書籍和課程，用於系統設計面試準備。它包含《系統設計訪談》第一捲和第二卷的所有內容，並將隨即將推出的第三卷進行更新。
-
Exponent ：一個專為面試準備的網站，特別是針對亞馬遜和谷歌等 FAANG 公司，他們還有很棒的系統設計課程和許多其他材料，可以幫助您破解 FAAN 面試。
image_credit - ByteByteGo
結論
這就是REST、GraphQL 和 gRPC 技術之間的差異。簡而言之，REST 是一種用於建立Web 服務的流行協議，受到HTTP 的啟發並充分利用HTTP 提供的功能，而GraphQL 是一種查詢語言，允許客戶端準確指定他們需要從伺服器獲取哪些資料。
它的建立是為了解決 REST 的缺點，因此如果您正在努力維護 REST API，那麼它絕對是一個可行的選擇。
另一方面， gRPC是一種高效能、開源協議，常用於微服務架構。
這些協定中的每一個都有不同的用途，並且它們都可以一起使用，為 Web 應用程式提供全面且高效的通訊系統。
原文出處：https://dev.to/somadevtoo/difference-between-graphql-rest-and-grpc-58bl
1) --- 會變成分隔線（上一行必須是空白）
2) # 會變成一級標題
3) ## 會變成二級標題
4) ### 會變成三級標題
5) **粗體文字**會顯示粗體文字
6) ```當第一行與最後一行會顯示程式碼
7) 請搜尋 Markdown 語法，了解各種格式