我們都知道，客戶端-伺服器架構將通訊分為兩部分：一部分承擔所有繁重的工作並提供服務，稱為伺服器，另一部分享受這些服務的人稱為客戶端。
在典型的客戶端-伺服器通訊中，客戶端只是向伺服器傳送資源或服務的請求，然後伺服器響應該請求。
對於客戶端-伺服器通訊，客戶端和伺服器需要具有能夠理解它們與之通訊的協議的庫。 協議是用於網際網絡通訊的一種語言或一組規則。 它們是傳輸機制，遵循一些通過 Internet 傳輸資料的準則。
客戶端通訊的第二個最重要的方面是客戶端和伺服器都可以識別的訊息格式。 此訊息格式遵循一種格式，如果不遵循它們就無法進行通訊。 訊息格式可以類似於 XML（特定表單）或 JSON 檔案（必須包含特定的鍵值對）。 關於這種型別的通訊，需要了解的另乙個重要方面是它基於請求和響應機制，這意味著伺服器僅在客戶端發起請求時進行通訊。
在 20 世紀初，一種稱為 SOAP 的流行客戶端-伺服器協議將 XML 訊息格式與硬編碼模式一起使用。 這種訊息格式的模式非常嚴格，並且嚴格按照指定的規則進行編碼，這導致了SOAP的逐漸放棄和REST的出現。 REST的出現是由於j**ascript的日益普及，這也直接導致了json檔案格式的流行。 它簡單易懂且方便。 它的訊息格式只有幾個鍵值對。 簡單來說，REST就是使用HTTP作為協議（傳輸機制）的JSON訊息的傳輸。 使用 REST，我們無需擔心如何開發訊息傳遞模式。
我們已經談到了REST的出現，讓我們仔細看看它的核心技術。 我們來看一下定義，REST是一種標準化的軟體架構風格，是業界廣泛使用的API。
1. REST簡單，有一套通訊架構標準。 使用 REST，我們不必每次都格式化訊息或資料。
2. REST是可擴充套件的。 如果您的服務變得更加複雜並需要更多功能，您可以輕鬆地改造伺服器端，而無需擔心伺服器的 REST 效能，並且可以完全隔離地新增新功能。
3. REST是無狀態的。 以前，每個請求都攜帶一些伺服器可以理解的資訊，伺服器的機制允許伺服器記住請求的資訊，但在REST架構中，會話狀態儲存在客戶端上，這使得伺服器效率更高，給伺服器帶來的工作量更少，從而實現更好的功能。
4. REST是高效能架構，支援快取。
想象一下，你正在為一家餐廳做乙個**。 您可以**獲取所有選單，食物分為三類：
1.開胃菜。 2.主菜。
3.飲料。 現在想**看看所有的飲料。 在REST架構中，我們可以輕鬆地對這些資訊進行分類，並向伺服器傳送GET請求，以獲取飲料的資料。 同樣，我們也可以做所有的CRUD（建立、讀取、更新、刪除），這使得REST適用於不需要超傳輸資料、不需要實時的大型專案。 REST 對於專注於高效資料傳輸的應用程式最有效。 快取是REST的另乙個功能，它對標準應用程式很有用，例如食品預訂應用程式，酒店預訂應用程式，部落格，論壇等。
REST功能強大，但也有一些缺點。
1.沒有雙向通訊，如果伺服器需要向客戶端傳送一些資料怎麼辦？ 在 REST 體系結構中，這是不可能的。 當然，您可以使用一些技巧，但它們不實用。
2. 想象一下獲得實時分數**。 您將如何實現此更新分數的功能？ 我們可以讓客戶端每 10 秒傳送一次請求，但這不是乙個好的做法。 它使伺服器過載，從而降低了伺服器響應的效率。
3. REST架構是純粹的請求和響應，不支援資料流（連續事件處理）。
4. REST無狀態屬性既有優點也有缺點，因為我們無法判斷REST架構上資料的狀態。
為了解決REST的第乙個問題，即雙向通訊的需求，WebSocket出現了，它允許伺服器發起通訊，但是WebSocket的問題在於它沒有格式，它只能傳送位元組，沒有任何限制。
websockets本身並沒有什麼問題，但真正的問題是，任何型別的通訊都需要乙個協議，並且每個協議都需要乙個可以與該協議通訊的客戶端庫（解析資料）。
如果要在基於 REST 的體系結構上建立 Python 應用程式，則需要乙個可以與伺服器通訊的 HTTP 客戶端。 在大多數情況下，客戶端庫是由第三方開發的。 使用第三方庫可能會暴露您自己的程式詳細資訊，不安全，並且整個應用程式將依賴第三方進行通訊。
對於 Web 應用程式，瀏覽器的作用類似於客戶端庫，但對於非 Web 專案，您需要第三方客戶端庫。 如果我們自己開發乙個應用程式，那就沒那麼容易了，你將有維護另乙個應用程式的負擔。
因此，為了解決 REST 的一些問題以及客戶端庫的問題，Google 在 2015 年發明了 GRPC。
對於 gRPC，Google 為幾乎所有流行語言維護了乙個客戶端庫。 它在後台使用 HTTP 2 協議，並使用 Protobuf 作為其訊息格式。 我們不需要擔心任何客戶端庫，因為 Google 正在為所有程式語言維護它。 單一的集中式客戶端庫是 grpc 的主要優勢之一。
grpc 的另乙個好處是它使用的訊息格式。 Protobuf 與語言無關，因此我們可以在 Python 中建立乙個客戶端，在 Go 中建立乙個伺服器，並且仍然能夠輕鬆通訊。
GRPC 本質上是乙個客戶端庫，也是一種可以在任何裝置上使用的協議。
GRPC 使用 Protobuf 進行通訊。 它將原型檔案序列化為二進位格式並將它們傳送到伺服器，在伺服器端將它們反序列化為原始格式。 同時，GRPC有不同的溝通形式。 可以將它們視為 gRPC 的函式。
單個請求：一種簡單的請求-響應通訊型別，客戶端傳送原始請求，伺服器在收到請求後等待一段時間以執行某些程序，然後返回一些響應。
伺服器流式處理：當發出單個請求時，伺服器會使用大量資料進行響應。 例如，當點選某個**時，大量與**相關的資料從伺服器端湧出。
客戶端流式處理：與伺服器流相反。 在這裡，客戶端一次向伺服器傳送大量資料。 例如，當您在 Internet 上共享大檔案或將影象或 ** 上傳到 Internet 時，就會發生這種情況。 客戶端不斷向伺服器端傳送資料。
雙向流動：在這種型別的通訊中，客戶端和伺服器傳送多條訊息。 聊天就是乙個很好的例子。
根據 gRPC 的功能，假設您要製作乙個聊天應用程式。 我們不會使用 REST API，因為它無法允許快速的雙向通訊流。 ，我們將使用 gRPC 流，這將提供比速度更多的好處。 首先，它的跨語言行為獨立於伺服器或其他客戶端編寫的程式語言。 在接受訊息格式之前，仍可以建立通訊。
因此，借助此功能，聊天應用程式的 Android 版本可以與 iOS 版本進行通訊，反之亦然。
有限的瀏覽器支援：gRPC 使用 HTTP 2，因此很難直接從瀏覽器呼叫 gRPC 服務。 有時需要設定**。
不可讀的表單：grpc 使用人類無法讀取的二進位格式。 在某些情況下，這是乙個缺點。
幼稚：gRPC 是在 2015 年開發的，所以與 REST 相比它仍然有點不成熟，有很多錯誤和問題需要解決。
入職成本：REST和GraphQL使用JSON，更易學。 大多數人會嘗試堅持使用它們，因為 protobuf 仍然是乙個新穎而複雜的話題，因此很難找到 grpc 專家。
資料格式：
REST使用的訊息格式主要是JSON（有時是XML），這種格式更易讀，更易於使用。 我們不必擔心REST中的模式。 而 grpc 使用協議緩衝區來序列化資料。 壓縮形式更輕，攜帶速度更快。 它採用二進位格式，因此資料在傳輸過程中被序列化和反序列化。
http 1.1 vs http 2：
REST API 通常使用 HTTP 11 作為其協議，而 grpc 使用 HTTP 2 作為其底層協議。 REST API 也可以使用 HTTP 2，但由於 REST 請求-響應機制，它仍然會受到限制。 GRPC 使用 HTTP 2 並利用 HTTP 2 支援進行客戶端響應和雙向通訊。 這是 grPC 優於 REST 的另乙個方面。 它可以像 http 1 一樣1 管理單向請求，或同時管理雙向請求，如 HTTP 2。
延遲：
grPC 的低延遲和高通訊速度使其成為連線由輕量級微服務架構組成的系統的理想選擇，從而實現更高效的訊息傳遞。 在大多數網路情況下，REST 延遲需要 25ms，而 grPC 延遲比 REST 小得多。
負載限制：
傳輸訊息時，REST 的最大負載限制為 45MB，而 grPC 沒有任何限制，這意味著傳輸訊息可以具有所需的大小。
安全：
在安全性方面，REST落後，因為它使用HTTP 11和JSON格式，易於解密和訪問。 另一方面，grPC 使用更安全的 HTTP 2，並使用二進位格式的 Protobuf，難以解密。
速度：
在這裡，grpc 再次獲勝，因為它比 REST 快 10 倍，出於同樣的原因，http 2 被用作協議，protobuf 被用作訊息格式。
**生成：
REST 不提供內建的生成功能，這意味著開發人員需要第三方應用程式來生成 API，而 gRPC 具有原生生成功能，這要歸功於其與多種程式語言相容的 ProtoBOF 編譯器。 這是另乙個好處，特別是對於微服務架構。
最後，我想說的是，REST仍然是最常用和最流行的架構，它不可能放棄。 REST有很多缺點，比如缺乏資料流、沒有雙向通訊、速度慢等，但它最適合我們在日常生活中看到的標準應用程式。 另一方面，grPC 還很年輕，很難學習，它提供了許多功能，例如客戶端和伺服器端的資料流量都很高，雙向資料流良好，快速緊湊，並且使用 HTTP 2。 在效能方面，grPC 最適合高工作負載應用程式，例如流媒體、歌曲流媒體、遊戲、檔案共享和聊天應用程式。
**10,000粉絲獎勵計畫