gRPC 與 REST 之間有何差異？
您可以透過 gRPC 和 REST 兩種方式設計 API。API 是使用一組定義和協定，讓兩個軟體元件彼此通訊的機制。在 gRPC 中，一個元件 (用戶端) 呼叫或調用另一個軟件元件 (伺服器) 中的特定功能。在 REST 中，用戶端會請求或更新伺服器上的資料，而不是呼叫函數。
什麼是 gRPC？
什麼是 RPC？
在 RPC 中，用戶端-伺服器通訊就像用戶端 API 請求是本機作業，或者請求是內部伺服器程式碼一樣運作。
在 RPC 中，用戶端會將請求傳送至伺服器上一律接聽遠端呼叫的程序。在請求中，包含要呼叫的伺服器函數，以及要傳遞的任何參數。RPC API 會使用 HTTP、TCP 或 UDP 等協定，來做為其基礎資料交換機制。
gRPC 與 RPC 之間有何差異？
gRPC 是一種實作傳統 RPC 並提供多項優化的系統。例如，gRPC 使用協定緩衝區和 HTTP 2 進行資料傳輸。
它還會抽象化開發人員的資料交換機制。例如，另一個廣泛使用的 RPC API 實作，OpenAPI，需要開發人員將 RPC 概念映射至 HTTP 協定。但 gRPC 會抽象化基礎 HTTP 通訊。相較於其他 RPC 實作，這些優化可讓 gRPC 更快捷、更容易實作，且更適合網路使用。
什麼是 REST？
REST 是一種軟體架構方法，定義了在軟體元件之間交換資料的規則集。它以 HTTP 為基礎，這是 Web 標準通訊協定。RESTful API 透過 POST、GET、PUT 和 DELETE 之類的 HTTP 動詞來管理用戶端與伺服器之間的通訊，以進行建立、讀取、更新和刪除作業。透過稱為端點的 URL 來識別伺服器端資源。
REST 運作方式如下：
- 用戶端發出建立、修改或刪除伺服器上資源的請求
- 該請求包含資源端點，還可能包括其他參數
- 伺服器回應，在作業完成後將整個資源傳回給用戶端
- 該回應包含採用 JSON 格式和狀態碼的資料
使用 REST 指導方針建置的 API 稱為 RESTful API 或 REST API。
為什麼組織使用 gRPC 和 REST？
gRPC 和 REST 是開發 API 的兩種不同方法。
API 操作類似於透過菜單從餐廳訂購食物。在任何餐廳，客戶 (用戶端) 都可從菜單 (API) 訂購食物，菜單具有固定的菜餚。這會傳達給廚房 (伺服器)，以準備請求的菜餚，並將其傳送給客戶。客戶不需要知道廚房如何下訂單，只需要知道送回的菜餚。菜單格式標準化意味著客戶和廚房都知道如何使用。
若沒有 API，關於不同的應用程式或軟體服務如何通訊，就不會達成共同的協議。兩個單獨應用程式的程式設計人員需要相互交談，以確定如何構建出每次交換的資料。
存在不同類型的 API 架構，例如 gRPC 和 REST，因為不同的架構可以更好地適用於組織內的不同使用案例。API 設計人員必須根據系統需求，選擇自己喜好的用戶端-伺服器架構。
gRPC 與 REST 之間有什麼相似之處？
REST 和 gRPC 與 API 架構方法一樣有某些固有的相似之處。
資料交換機制
兩者都允許兩個軟體元件 (用戶端和伺服器) 依據共用的規則集來進行通訊和交換資料。無論每個軟體元件內部的運作方式為何，這些規則都適用。
以 HTTP 為基礎的通訊
兩者都透過 HTTP 請求-回應機制 (Web 的首選高效通信協定) 傳遞資料。不過，在 gRPC 中，這對開發人員來說是隱藏的，而在 REST 中，則更為明顯。
實作靈活性
您可在各種程式設計語言中實作 REST 和 gRPC。這種品質讓其可在程式設計環境中具有很高的可攜性。這樣可實現最佳互操作性與近乎通用的支援。
適用於可擴展的分散式系統
gRPC 和 REST 都使用下列各項：
- 非同步通訊，讓用戶端和伺服器可在不中斷作業的情況下進行通訊
- 無狀態設計，讓伺服器不必記住用戶端狀態
這意味著開發人員可使用 gRPC 和 REST 來建置具有大量並行請求的防故障系統。您可以使用多個用戶端，來建置可擴展的分散式系統。
架構原則：gRPC 與REST
雖然 REST 和 gRPC 均提供類似的功能，但基礎模型在其架構上有很大差異。
通訊模式
使用 REST API，用戶端會將單一 REST API 請求傳送至伺服器，然後伺服器會在回覆中傳送單一回應。用戶端必須等待伺服器回應，再繼續作業。這種機制是一種請求-回應模型，且採用一元資料連線 (一對一)。
相較之下，使用 gRPC 時，用戶端可將一個或多個 API 請求傳送至伺服器，這可能導致伺服器產生一個或多個回覆。資料連線可以是一元 (一對一)、伺服器串流 (一對多)，用戶端串流 (多對一) 或雙向串流 (多對多)。這種機制是一種用戶端回應通訊模型，由於 gRPC 以 HTTP 2 為基礎，因此這是可能的。
伺服器上的可呼叫作業
在 gRPC API 中，可呼叫的伺服器作業由服務定義，也稱為函數或程序。gRPC 用戶端會調用這些函式，就像在應用程式內部呼叫函數一樣。這被稱為服務導向型設計。下面是一個範例：
createNewOrder(customer_id, item_id, item_quantity) -> order_id
在 REST 中，用戶端可在 URL 定義的伺服器資源上使用的一組有限的 HTTP 請求動詞。用戶端呼叫資源本身。這被稱為實體導向型設計。實體導向型設計與物件導向型程式設計方法很好地保持一致。下面是一個範例：
POST /orders <headers> (customer_id, item_id, item_quantity) -> order_id
雖然您可以使用實體導向方法來設計 gRPC API，但這並非系統本身的限制。
資料交換格式
使用 REST API，在軟體元件之間傳遞的資料結構通常會以 JSON 資料交換格式表示。它也可以傳遞其他資料格式，如 XML 和 HTML。JSON 易於讀取且靈活，但必須序列化並轉譯為程式設計語言。
相較之下，gRPC 預設會使用協定緩衝區 (Protobuf) 格式，但它也會提供原生 JSON 支援。伺服器會使用原型規格檔案中的協定緩衝區介面描述語言 (IDL) 來定義資料結構。gRPC 則會將結構序列化為二進制格式，然後將其還原序列化為任何指定的程式設計語言。JSON 在傳輸期間不會被壓縮，而這種機制讓它比使用 JSON 更快。與 JSON 搭配使用的 REST API 不同，協定緩衝區並非人類可讀。
其他主要差異：gRPC 與REST
其他主要差異：gRPC 與REST
除了架構樣式之外，gRPC 和 REST 還有其他固有的差異。
用戶端-伺服器耦合
REST 為鬆耦合，這意味著用戶端和伺服器不需要了解有關其他實作的任何資訊。這種鬆耦合讓 API 更容易隨時間而演進。這是因為伺服器定義的變更不一定需要在用戶端中變更程式碼。
gRPC 為緊耦合，這意味著用戶端和伺服器必須能夠存取相同的原型檔案。檔案的任何更新都需要在伺服器和用戶端中進行更新。
產生程式碼
gRPC 提供用戶端和伺服器端原生程式碼產生功能的內建選項。由於採用協定緩衝區編譯器，它們能以多種語言提供。在原型檔案中定義結構之後，gRPC 會產生用戶端和伺服器端程式碼。程式碼產生可減少 API 開發耗時的時間。
另一方面，REST 不提供任何內置程式碼產生機制，因此，如果開發人員需要此功能，則必須使用其他第三方工具。進一步了解程式碼產生。
雙向串流
gRPC 提供雙向串流通訊。這意味著用戶端和伺服器可在單一連線同時傳送和接收多個請求和回應。
REST 不提供此功能。
何時使用 gRPC 與REST
REST 是目前最受青睞的 Web 服務和微型服務架構的 API 架構。REST 之所以受青睞，是因為其簡單的實作和資料結構映射、可讀性和靈活性。對於程式設計人員新手來說，無論是用於 Web 服務開發還是內部微型服務，都可以輕鬆開始為其應用程式開發 RESTful API。
以下是 REST API 的使用案例：
- 以 Web 為基礎的架構
- 便於外部使用者理解的公開 API
- 簡單的資料通訊
與 REST 不同，gRPC 專門設計用於讓開發人員能夠針對分散式資料中心的微型服務架構建立高效能 API。它更適合需要即時串流和大量資料載入的內部系統。當 API 不太可能隨時間變更時，gRPC 也非常適合包含多種程式設計語言的微型服務架構。
gRPC API 更適合下列使用案例：
- 高效能系統
- 高資料載入
- 即時或串流應用程式
關於 Web 軟體開發的注意事項
雖然 HTTP 是核心 Web 協定，但存在不同版本的 HTTP，在 Web 瀏覽器和 Web 伺服器之間採用也有所差異。
gRPC API 始終使用 HTTP 2，而 REST API 通常使用 HTTP 1.1，這是不同的 HTTP 協定。雖然 HTTP 2 現在是一種常用的 Web 協定，但與 HTTP 1.1 不同，它並不具有通用瀏覽器支援。對於想要支援 Web 應用程式的開發人員來說，這種有限的瀏覽器支援可能會使 gRPC 成為稍遜的選項。
差異摘要：gRPC 與REST
| gRPC API |
REST API |
|
| 這是什麼？ |
依據 Remote Procedure Call (RPC) 用戶端-伺服器通訊模型建立及使用 API 的系統。 |
用於定義用戶端與伺服器之間的結構化資料交換的規則集。 |
| 設計方法 |
服務導向型設計。用戶端會要求伺服器執行可能會或可能不會影響伺服器資源的服務或功能。 |
實體導向型設計。用戶端會要求伺服器建立、共用或修改資源。 |
| 通訊模式 |
多種選項，例如一元、一部伺服器至多個用戶端、一個用戶端至多部伺服器，以及多個用戶端至多部伺服器。 |
一元。單一用戶端與單一伺服器進行通訊。 |
| 實作 |
需要用戶端和伺服器端上的 gRPC 軟體才能運作。 |
您可以在用戶端和伺服器端以多種格式實作，而無需常用軟體。 |
| 資料存取 |
服務 (函數) 呼叫。 |
採用 URL 形式用於定義資源的多個端點。 |
| 傳回的資料 |
採用協定緩衝區檔案中所定義服務的固定傳回類型。 |
採用伺服器定義的固定結構 (通常是 JSON)。 |
| 用戶端-伺服器耦合 |
緊耦合。用戶端和伺服器都需要定義資料格式的相同協定緩衝區檔案。 |
鬆耦合。用戶端和伺服器不知道內部詳細資訊。 |
| 自動化程式碼產生 |
內建功能。 |
需要第三方工具。 |
| 雙向串流 |
存在。 |
不存在。 |
| 最適合 |
高效能或資料密集型微型服務架構。 |
明確定義資源的簡單資料來源。 |
AWS 如何支援您的 gRPC 和 REST 需求？
Amazon Web Services (AWS) 提供一系列服務和工具，可協助 API 設計人員建置、執行和管理以 API 為基礎的現代應用程式和服務。如需詳細資訊，請參閱在 AWS 上建置現代應用程式的相關內容。
以下是針對您的 API 需求提供支援的 AWS 產品範例：
- Amazon API Gateway 可讓開發人員大規模建立、發布和管理 API。使用 API Gateway，您可以建置針對容器化微型服務架構和 Web 應用程式進行優化的 RESTful API。
- Elastic Load Balancing (ELB) 可分配網路流量以提高應用程式可擴展性。其可在微型服務之間或啟用 gRPC 的用戶端與服務之間路由 gRPC 流量和進行負載平衡。這樣可在架構中順暢地引入 gRPC 流量管理，而無需變更客戶的用戶端或服務上的任何底層基礎設施。
- Amazon Virtual Private Cloud (Amazon VPC) Lattice 是一項應用程式聯網服務，可持續連線、監控和保護服務之間的通訊。自動擴展運算和網路資源，以支援高頻寬 HTTP、HTTPS 和 gRPC 工作負載。
立即建立帳戶，開始使用 AWS 上的 gRPC 和 REST。
