RPC 、REST、GraphQL三種API設計方式的簡介和比較

RPC

RPC=remote procedure call，執行遠程服務器上的一個function，舉例：
服務端定義了三個函數：

客戶端發起請求

RPC在一些大公司中依然被使用。
RPC的優勢有：

• 設計簡潔，便於理解
• 輕量的payload
• 很高的性能表現

缺點有：

• 先後端代碼高耦合
• 代碼可讀性很差，相關代碼不容易被定位
• 會致使有大量被定義的函數，難以管理

REST

REST = Representational state transfer，直接翻譯就是『表現層狀態轉移』
優勢：

• 先後端高度解耦
• 便於理解，即便沒有看文檔，也能大概知道接口是用來作什麼的；
• 接口的功能有單一性，便於擴展和複用；
• 利用了HTTP本來的特性

缺點：

• 有時payload會變的特別大
• 同一個頁面可能要調用不少個API，來獲取不一樣的東西，在網絡差的狀況下會下降體驗

舉例：

GraphQL

GraphQL = Graph query language
吸收了RPC和REST的一些共同優勢；以查詢爲基本單元，方便獲取到想要的數據，舉例：
接口定義

接口調用

優勢：

• 低網絡速度下表現優異
• 聲明式地數據獲取
• 根據UI需求獲取合適的數據，避免沒必要要的數據傳輸

缺點：

• 定義起來相對複雜
• 緩存問題，須要一個更加健全的機制中來確保字段級別的緩存
• 版本持續更新中，還不太成熟

綜合對比與總結

API設計也不會有銀彈。
設計API時，決定使用哪一種形式，得先考慮所設計的API將會被誰使用：

• 若是是關注於對象和資源的項目，須要對接各類不一樣的端和使用者，須要便於使用和閱讀文檔，那麼適合使用REST
• 若是是面向行爲動做，或者內部的一些微服務，對響應要求高，那麼能夠考慮RPC
• 若是是須要給UI提供數據，或者須要對弱網絡環境下優化而減小請求，那麼能夠考慮GraphQL

參考來源

https://www.youtube.com/watch...