RPC 與 REST 之間有何差異？
Remote Procedure Call (RPC) 和 REST 是 API 設計中的兩種架構樣式。API 是使用一組定義和協定讓兩個軟體元件彼此通訊的機制。軟體開發人員使用之前開發的或第三方元件來執行功能，因此他們不必從頭開始編寫所有內容。RPC API 可讓開發人員呼叫外部伺服器中的遠端功能，就如同軟體在本機一樣。例如，您可以藉由遠端呼叫其他聊天應用程式上的訊息傳送功能，將聊天功能新增至應用程式。相較之下，REST API 可讓您在遠端伺服器上執行特定的資料作業。例如，您的應用程式可以使用 REST API 在遠端伺服器上插入或修改員工資料。
RPC 與 REST 之間有什麼相似之處？
Remote Procedure Call (RPC) 和 REST 都是設計 API 的方法。API 在現代 Web 設計和其他分散式系統中至關重要。它們允許兩個獨立的分散式應用程式或服務進行通信，而無需知道另一個應用程式的內部如何運作。除了小型資料交換之外，這兩個應用程式或服務可能彼此沒有什麼關係。
API 也是程式後端 (邏輯元件) 與程式前端 (顯示元件) 通訊的常用機制。當您使用 API 設計網頁和 Web 應用程式，而不是緊密耦合的整合時，您可以確保其能夠以較少的程式碼重寫來擴展和變更。
接下來，我們討論 RPC 與 REST API 之間的其他相似之處。
抽象化
雖然網路通訊是 API 的主要目的，但較低層級的通訊本身是透過 API 開發人員抽象出來的。這讓開發人員能夠專注於功能而不是技術實作。
通訊
REST 和 RPC 都使用 HTTP 作為基礎協定。RPC 和 REST 最常用的訊息格式是 JSON 和 XML。JSON 因其可讀性和靈活性而受到青睞。
跨語言相容性
開發人員可以使用他們選擇的任何語言來實作 RESTful 或 RPC API。因此，只要 API 的網路通訊元素符合 RESTful 或 RPC 介面標準，您就可以使用任何程式設計語言來撰寫其餘的程式碼。
架構原則：RPC 與REST
在 Remote Procedure Call (RPC) 中，用戶端會在伺服器上進行遠端函數 (也稱為方法或程序) 呼叫。通常，一個或多個資料值在呼叫期間會傳遞至伺服器。
相較之下，REST 用戶端會請求伺服器對特定伺服器資源執行動作。動作僅限於建立、讀取、更新和刪除 (CRUD)，並以 HTTP 動詞或 HTTP 方法的形式傳達。
RPC 專注於功能或動作，而 REST 則專注於資源或物件。
RPC 原則
接下來，我們討論 RPC 系統通常遵循的一些原則。不過，這些原則並不像 REST 那樣標準化。
遠端調用
RPC 呼叫由用戶端對遠端伺服器上的函數進行，就像在本機呼叫用戶端一樣。
傳遞參數
用戶端通常將參數傳送給伺服器函數，與本機函數大致相同。
Stub
函數 Stub 同時存在於用戶端和伺服器上。在用戶端上，它讓函數能夠呼叫。在伺服器上，它調用實際函數。
REST 原則
REST 原則為標準化。REST API 必須遵循這些原則，才能被歸類為 RESTful。
用戶端-伺服器
REST 的用戶端-伺服器架構可將用戶端和伺服器分離。它將其視為獨立的系統。
無狀態
伺服器不保留用戶端請求之間用戶端狀態的任何記錄。
可快取
用戶端或中介系統可根據用戶端是否指定回應可被快取，來快取伺服器回應。
分層系統
中介機構可存在於用戶端和伺服器之間。用戶端和伺服器都不知道它們，並且像直接連線那樣運作。
統一介面
用戶端和伺服器透過一組標準化指示和訊息格式與 REST API 進行通訊。資源透過其 URL 識別，並且此 URL 稱為 REST API 端點。
運作方式：RPC 與REST
在 Remote Procedure Call (RPC) 中，用戶端使用 HTTP POST 依名稱呼叫特定函數。用戶端開發人員必須事先知道函數名稱和參數，RPC 才能運作。
在 REST 中，用戶端和伺服器使用 GET、POST、PATCH、PUT、DELETE 和 OPTIONS 之類的 HTTP 動詞來執行選項。開發人員只需要知道伺服器資源 URL，而不必關注個別函數名稱。
下表顯示了用戶端用於在 RPC 和 REST 中執行類似動作的程式碼類型。
| 動作 |
RPC |
REST |
評論 |
| 將新產品新增至產品清單 |
POST /addProduct HTTP/1.1 HOST: api.example.com Content-Type: application/json {"name": "T-Shirt", "price": "22.00", "category": "Clothes"} |
POST /products HTTP/1.1 HOST: api.example.com Content-Type: application/json {"name": "T-Shirt", "price": "22.00", "category": "Clothes"} |
RPC 對函數使用 POST，REST 對 URL 使用 POST。 |
| 擷取產品詳細資訊 |
POST /getProduct HTTP/1.1 HOST: api.example.com Content-Type: application/json {"productID": "123”} |
GET /products/123 HTTP/1.1 HOST: api.example.com |
RPC 對函數使用 POST，並將參數作為 JSON 物件傳遞。REST 對 URL 使用 GET，並在 URL 中傳遞參數。 |
| 更新產品價格 |
POST /updateProductPrice HTTP/1.1 HOST: api.example.com Content-Type: application/json {"productId": "123", "newPrice": "20.00"} |
PUT /products/123 HTTP/1.1 HOST: api.example.com Content-Type: application/json {"price": "20.00"} |
RPC 對函數使用 POST，並將參數作為 JSON 物件傳遞。REST 對 URL 使用 PUT，在 URL 中傳遞參數並作為 JSON 物件。 |
| 刪除產品 |
POST /deleteProduct HTTP/1.1 HOST: api.example.com Content-Type: application/json {"productId": "123""} |
DELETE /products/123 HTTP/1.1 HOST: api.example.com |
RPC 對函數使用 POST，並將參數作為 JSON 物件傳遞。REST 對 URL 使用 DELETE，並在 URL 中傳遞參數。 |
主要差異：與REST
接下來，我們將介紹更多不同之處。
開發時間
RPC 於 20 世紀 70 年代末和 80 年代初開發，而 REST 則是首個由電腦科學家 Roy Fielding 於 2000 年創造的術語。
作業格式
由於 HTTP 方法，REST API 具有一組標準化伺服器作業，但 RPC API 則沒有。某些 RPC 實作提供標準化作業的架構。
資料傳遞格式
REST 可在同一個 API 內傳遞任何資料格式和 JSON 和 XML 等多種格式。
但是，使用 RPC API 時，伺服器會選取資料格式，並在實作期間固定資料格式。您可以擁有特定的 JSON RPC 或 XML RPC 實作，並且用戶端沒有彈性。
州
在 API 的內容中，無狀態是指伺服器不存放有關用戶端之前互動之任何資訊的設計原則。每個 API 請求都是獨立處理，並且伺服器不依賴任何存放的用戶端狀態來處理請求。
REST 系統必須始終無狀態，但 RPC 系統可以具狀態或無狀態的，具體取決於設計。
何時使用：RPC 與REST
Remote Procedure Call (RPC) 通常用於呼叫伺服器上需要動作結果的雲端功能。若您需要複雜的計算或想要在伺服器上觸發遠端程序，並且需要在用戶端中隱藏程序時可以使用。
在以下動作中 RPC 是不錯的選擇：
- 使用遠端裝置的相機拍照
- 在伺服器上使用機器學習演算法來識別詐騙
- 在遠端銀行系統將資金從一個帳戶轉移至另一個帳戶
- 在遠端重新啟動伺服器
REST API 通常用於在伺服器上，對資料物件執行建立、讀取、更新和刪除 (CRUD) 作業。這使得 REST API 非常適合需要統一公開伺服器資料和資料結構的情況。
在以下動作中 REST API 是不錯的選擇：
- 將產品新增至資料庫
- 擷取音樂播放清單的內容
- 更新人員的地址
- 刪除部落格文章
為什麼 REST 要取代 RPC？
雖然 REST Web API 在今天很常見，但 Remote Procedure Call (RPC) 並沒有消失。REST API 通常用於應用程式，因為開發人員更容易理解和實作。但 RPC 仍然存在，並在更適合使用案例時使用。
RPC 的現代實作 (例如 gRPC) 現在更受青睞。在某些使用案例中，gRPC 的效能優於 RPC 和 REST。它允許串流用戶端-伺服器通訊，而不是請求和回應資料交換模式。
差異摘要：RPC 與REST
| RPC |
REST |
|
| 這是什麼？ |
系統允許遠端用戶端呼叫伺服器上的程序，就像在本機一樣。 |
用於定義用戶端與伺服器之間的結構化資料交換的規則集。 |
| 用於 |
在遠端伺服器上執行動作。 |
對雲端物件的建立、讀取、更新和刪除 (CRUD) 作業。 |
| 最適合 |
需要複雜計算或在伺服器上觸發遠端程序的情況。 |
伺服器資料和資料結構需要統一公開的情況。 |
| 具狀態 |
具狀態或無狀態。 |
無狀態。 |
| 資料傳遞格式 |
採用伺服器定義並在用戶端上強制執行的一致結構。 |
採用伺服器獨立確定的結構。可在同一 API 中傳遞多種不同的格式。 |
AWS 如何支援您的 API 需求？
Amazon Web Services (AWS) 提供一系列服務和工具，可協助 API 設計人員建置、執行和管理以 API 為基礎的現代應用程式和服務。如需詳細資訊，請參閱在 AWS 上建置現代應用程式的相關內容。
以下是可協助您滿足 API 需求的 AWS 服務範例：
- Amazon API Gateway 可讓開發人員大規模建立、發布和管理 API。使用 API Gateway，您可以建置針對容器化微型服務架構和 Web 應用程式進行優化的 REST API。
- Elastic Load Balancing (ELB) 可分配網路流量以提高應用程式可擴展性。其可在微型服務之間或啟用 gRPC 的用戶端與服務之間路由 gRPC 流量和進行負載平衡。這樣可在軟體架構中進行無縫的 gRPC 流量管理，而無需變更客戶的用戶端或服務的任何底層基礎設施。
- Amazon Virtual Private Cloud (Amazon VPC) Lattice 是一項應用程式聯網服務，可持續連線、監控和保護服務之間的通訊。自動擴展運算和網路資源，以支援高頻寬 HTTP、HTTPS 和 gRPC 工作負載。
立即建立帳戶，開始使用 AWS 上的 REST API 和 Remote Procedure Call (RPC) API。
