受歡迎的客戶端-伺服器架構將通訊分為兩部分：一部分承擔所有繁重任務並提供服務，稱為伺服器；另一部分享受這些服務，稱為客戶端。
在一般的客戶端-伺服器通訊中，客戶端僅需發送請求，要求伺服器提供資源或服務，而伺服器則回應該請求。
對於客戶端-伺服器通訊，客戶端和伺服器需具備能理解它們通訊協議的庫。協議是一種語言或互聯網通訊規則的集合。它們是遵循某些數據傳輸指南的傳輸機制。
客戶端通訊的第二個重要方面是消息格式，客戶端和伺服器需就此達成共識。此消息格式基於某些模式，若不遵循這些模式，通訊將無法進行。消息格式可能類似於遵循模式的XML，或是必須包含特定鍵值對的JSON文件。
理解這種通訊方式的另一個重要方面是，它基於請求和回應機制，意味著伺服器僅在客戶端發起通訊時才進行通訊。使用REST和GraphQL時，這主要是單向的。這是將由gRPC等技術解決的基本問題。
為何REST會出現？
在90年代初期，一種流行的客戶端-服務器協議名為SOAP，它使用硬編碼結構的XML消息格式。該消息格式的結構非常僵硬。缺乏自由性導致了SOAP被棄用，以及REST的興起。
REST的出現是由於JavaScript的日益普及，這導致了JSON文件格式受歡迎程度的增長。它簡單易懂且方便，其消息格式僅包含一些鍵和值對。
簡而言之，REST是一種通過HTTP作為協議（傳輸機制）在互聯網上傳輸JSON消息的指導原則。使用REST，無需擔心創建結構。
什麼是REST？
我們討論了REST的出現。現在讓我們深入了解其核心技術。讓我告訴你，REST代表Representational State Transfer。REST是一種標準化的軟件架構風格，是行業中常用的API。
REST普及和廣泛使用的原因
- REST簡單且標準化，適用於通信架構。在利用R時，您無需擔心消息或數據的格式。您不必每次都擔心消息格式，因為它們都是標準化和行業使用的。
- REST具有可擴展性。如果您的服務變得更大並需要更多功能，您可以輕鬆地改造您的服務器，無需擔心REST服務器的性能，並且您可以在完全隔離的情況下創建新功能，除非它們破壞了您的數據。
- REST是無狀態的。這意味著每個請求都會攜帶一些數據，這些數據必須被伺服器理解。伺服器的架構使伺服器能夠回憶起該請求的信息，但在REST架構中，會話狀態存儲在客戶端，這使得伺服器更高效，並且伺服器對於更精細的功能負載較小。
- 最後但同樣重要的是，REST是一種高性能架構，並支持緩存。
何時使用REST
假設您正在為一家餐廳製作網站。您將所有菜單放在線上，並將食品項目分為三個類別：
- 開胃菜
- 主菜
- 飲料
現在，假設您想在線查看所有飲料。在REST架構中，您可以輕鬆且一致地將所有資源分區到API端點上。當然，您可以使用多種身份驗證來使其安全。
在這種情況下，我們向伺服器發送GET請求到一個端點，我們可以在該端點獲取飲料資源數據。
同樣，我們可以在REST API中執行所有CRUD（創建、讀取、更新、刪除）操作，這使得它適合不需要超高速數據傳輸且不需要實時性的大型項目。
REST最適合需要高效數據傳輸的項目。緩存是REST的另一個功能，對於標準應用程序（如食品預訂應用程序、酒店預訂應用程序、博客網站、在線論壇網站等）非常有用。
REST的限制和問題
REST雖然出色，但在某些情況下卻存在一些相當關鍵的缺點。讓我們來探討這些問題。
- 雙向通信的需求
若伺服器需要向客戶端發送數據怎麼辦？即伺服器希望主動發起通信。在REST架構中，這是不可能的。當然，你可以使用一些技巧，但它們並不實用。 - 試想建立一個即時比分網站。你將如何管理伺服器向客戶端發送請求以更新比分數據？我們可以讓客戶端每10秒發送一次請求，但這絕非良策。它會使伺服器過載，可能導致速度問題。
- REST架構完全是請求與回應，並不支持數據流（連續事件處理）。
- REST的無狀態特性既是福也是禍，因為你無法在REST架構中決定數據的狀態。
gRPC為何應運而生？
為了解決REST的首要問題——雙向通信的需求，WebSocket被發明出來，它允許伺服器主動發起通信，但問題在於它沒有固定的格式。它僅發送字節，沒有任何限制。
WebSocket本身並無問題，真正的問題在於任何類型的通信都需要一個協議，而每個協議都需要一個客戶端庫，以便使用該協議進行通信。
若您正在開發基於Rest架構的Python應用程式，您將需要一個能與伺服器通訊的HTTP客戶端。在許多情況下，這些客戶端庫是由第三方，主要是獨立開發者所製作。使用第三方庫可能會暴露您的安全性，且整個應用程式的通訊將依賴於第三方。
對於網頁應用程式，瀏覽器扮演著客戶端庫的角色，但對於非網頁專案，您將需要第三方客戶端庫。若您考慮自行開發，則需記住這並非易事，且您將需負責維護另一個應用程式。
因此，為了解決Rest及客戶端庫的一些問題，Google於2015年發明了gRPC。
對於gRPC，Google維護了一個幾乎涵蓋所有流行語言的客戶端庫。它內部使用HTTP 2協議，並以protocol buffer（protobuf）作為其訊息格式。
您無需擔心任何客戶端庫，因為Google正在為您維護它，幾乎適用於所有程式語言。單一且集中的客戶端庫是gRPC的一大優勢。
gRPC的另一個好處是其使用的訊息格式。Protocol buffer是語言無關的，因此您可以在Python中製作客戶端，在Go中製作伺服器，仍能無礙地通訊。
gRPC基本上是一個客戶端庫和一個可在任何設備上使用的協議。
什麼是gRPC？
gRPC採用protobuf進行通訊，將proto文件序列化為二進制格式後傳送至伺服器，伺服器端則將其反序列化回原始格式，這便是protobuf的運作機制。
gRPC提供多種通訊方式，可視為其特色功能。
gRPC的特色功能
- 單一請求：此為一種簡單的請求回應通訊模式，客戶端發送proto請求後，伺服器接收並等待一段時間進行處理，再回傳相應的回應。
- 伺服器串流：發出單一請求後，伺服器會回傳大量數據作為回應，例如點擊影片時，大量相關數據從伺服器湧出。
- 客戶端串流：與伺服器串流相反，此處客戶端一次性向伺服器發送大量數據，例如在網路上分享大型檔案或上傳圖片、影片時，客戶端持續向伺服器發送數據。
- 雙向串流：在此類通訊中，客戶端與伺服器可互傳多條訊息，聊天即為一典型範例。
這四項廣受歡迎的gRPC功能使其極具威力。
何時使用gRPC
至於gRPC的特性，我們已見識了一些使用案例。假設您想開發一款聊天應用，您不會選擇REST API，因為它無法實現快速的雙向通訊流。為此，我們將採用gRPC流，它不僅速度快，還有其他優勢。
首先，其語言中立性意味著無論伺服器或其他客戶端使用何種程式語言編寫，只要消息格式被接受，通訊就能建立。
因此，憑藉此特性，聊天應用的Android版本能與iOS版本互動，反之亦然。
gRPC的問題
萬物皆有瑕疵，gRPC亦不例外。
- 瀏覽器支援有限：gRPC基於HTTP 2，因此難以直接從瀏覽器呼叫gRPC服務，有時需設置代理。
- 不可讀格式：眾所周知，gRPC採用二進制格式，非人類可讀，這在某些情況下是劣勢。
- 成熟度不足：gRPC自2015年開發以來，與REST相比仍略顯稚嫩，尚有諸多漏洞與問題待解決。
- 學習難度：REST與GraphQL使用易學的JSON。多數人傾向於堅持使用它們，因為protobuf仍是新穎且複雜的議題，尋找gRPC專家頗具挑戰。
REST與gRPC之比較：
接下來，我們將探討REST與gRPC之間的技術差異。
訊息格式：
REST 使用的訊息格式多為 JSON（有時是 XML 格式），這種格式較易於閱讀和處理，且無需擔心 Schema 的問題。相對地，gRPC 使用 Protocol Buffers 來序列化數據，其壓縮形式更輕便且傳輸速度更快，由於是二進制格式，因此在序列化和反序列化數據以進行傳輸時更為高效。
HTTP 1.1 vs. HTTP 2：
REST API 通常使用 HTTP 1.1 作為其協議，而 gRPC 則在底層使用 HTTP 2。雖然 REST API 仍可使用 HTTP 2，但受限於請求-回應機制。gRPC 利用 HTTP 2 的優勢，支持客戶端-回應及雙向通訊，這使得 gRPC 在性能上優於 REST。它能夠同時處理 HTTP 1.1 的單向請求和 HTTP 2 的雙向請求。
延遲：
gRPC 在通訊中具有低延遲和高速度，適用於連接輕量級微服務架構的系統，從而提高訊息傳輸效率。在大多數網絡情況下，REST 的延遲約為 25ms，而 gRPC 的延遲遠低於 REST。
負載限制：
REST 在發送外向訊息時有最大負載限制 45MB，而 gRPC 則沒有此限制，意味著外向訊息的大小可以根據需求自由設定。
安全性：
在安全性方面，Rest因其使用HTTP 1.1和JSON格式而显得较为落后，这两种格式容易被解密和访问。相较之下，gRPC采用HTTP 2，安全性更高，且使用protobuf，这是一种二进制格式，难以被解密。
速度：
在这方面，gRPC同样胜出，其速度是Rest的10倍以上，这同样归功于其使用的HTTP 2协议和protobuf消息格式。
代码生成功能
Rest本身不提供内置的代码生成功能，这意味着开发者需要依赖第三方应用来生成API代码。而gRPC由于其protobuf编译器，具备原生的代码生成功能，并且兼容多种编程语言。这对微服务架构尤为有利。
孟菲斯REST网关
为了通过HTTP调用实现消息生产，满足各种使用场景及提高易用性，孟菲斯添加了一个HTTP网关，用于接收基于REST的请求（即消息）并将其生产到所需的站点。
受益于REST网关的常见用例包括：
- 直接从前端产生事件
- 使用HTTP服务器连接Debezium
- ArgoCD webhooks
- PostHog集成
- 通过HTTP调用从Fivetran/Rivery/任何ETL平台接收数据
孟菲斯REST网关配合JSON模式能有效提升数据质量，确保应用或服务间健康通信。
孟菲斯很快也将支持gRPC。
結論
總而言之，我想說的是，REST仍然是使用最廣泛且最受歡迎的架構，且不可能被放棄。REST雖然存在諸多缺點，如缺乏數據流傳輸、無雙向通信、速度較慢等，但它最適合我們日常生活中見到的標準應用。
另一方面，gRPC雖然較新且學習曲線陡峭，但提供了許多優勢，如客戶端與服務器端的高速數據流傳輸、良好的雙向數據流傳輸、快速且緊湊，並使用HTTP 2。由於其快速的性能，gRPC最適合高負載應用，如視頻流媒體、音樂流媒體、在線遊戲、文件共享和聊天應用。