REST APIs與微服務：關鍵差異
綁定到各種傳輸協議。 SOAP 在傳輸協議方面非常靈活，可以適應多種情況。
內置錯誤處理。 SOAP API 規范允許返回帶有錯誤代碼及其說明的重試 XML 消息。
許多安全擴展。 SOAP 與 WS-Security 協議集成，滿足企業級事務質量要求。它在事務中提供隱私和完整性，同時允許在消息級別進行加密。
SOAP 消息的一個示例。來源：IBM
SOAP API 邏輯是用 Web 服務描述語言 （WSDL） 編寫的。此 API 描述語言定義終端節點并描述可以執行的所有流程。這允許不同的編程語言和 IDE 快速建立通信。
SOAP 支持有狀態和無狀態消息傳遞。在有狀態方案中，服務器存儲接收到的信息可能非常繁重。但對于涉及多方和復雜交易的操作，這是合理的。
與語言和平臺無關。 用于創建基于 Web 的服務的內置功能允許 SOAP 處理通信并使響應獨立于語言和平臺。
綁定到各種傳輸協議。 SOAP 在傳輸協議方面非常靈活，可以適應多種情況。
內置錯誤處理。 SOAP API 規范允許返回帶有錯誤代碼及其說明的重試 XML 消息。
許多安全擴展。 SOAP 與 WS-Security 協議集成，滿足企業級事務質量要求。它在事務中提供隱私和完整性，同時允許在消息級別進行加密。
SOAP 消息級安全性：標頭元素和加密正文中的身份驗證數據
如今，很多開發人員因為各種原因而對必須集成SOAP API感到頭疼不已。
僅限 XML。 SOAP 消息包含大量元數據，并且僅支持請求和響應的詳細 XML 結構。
重量 級。 由于 XML 文件很大，SOAP 服務需要很大的帶寬。
狹義的專業知識。構建 SOAP API 服務器需要深入了解所有涉及的協議及其高度受限的規則。
繁瑣的消息更新。 嚴格的 SOAP 架構需要額外的工作來添加或刪除消息屬性，這會減慢采用速度。
目前，SOAP 架構最常用于企業內部或與其受信任的合作伙伴的內部集成。
高度安全的數據傳輸。 SOAP 剛性結構、安全性和授權功能使其成為在 API 和客戶端之間執行正式軟件合同的最合適選項，同時遵守 API 提供者和 API 消費者之間的法律合同。這就是金融機構和其他企業用戶選擇 SOAP 的原因。
REST 是一種不言自明的 API 架構風格，由一組架構約束定義，旨在被許多 API 使用者廣泛采用。
今天最常見的 API 樣式最初是由 Roy Fielding 在 2000 年的博士論文中描述的。REST 提供服務器端數據，以簡單的格式（通常是 JSON 和 XML）表示它。
REST 不像 SOAP 那樣嚴格定義。RESTful 架構應遵守 6 個架構約束：
事實上，一些服務只是在一定程度上是 RESTful 的。它們以 RPC 樣式為核心，將較大的服務分解為資源，并有效地使用 HTTP 基礎設施。但關鍵部分是使用超媒體（又名 HATEOAS），超文本作為應用程序狀態引擎的縮寫。基本上，這意味著REST API會為每個響應提供元數據，并附上關于如何使用該API的所有相關信息的鏈接。這就是使 Client 端和 Server 解耦的原因。因此，API 提供者和 API 使用者都可以獨立發展，而不會阻礙他們的通信。
Richardson 成熟度模型是實現真正完整和有用的 API 的目標，來源：Kristopher Sandoval
“HATEOAS 是 REST 的一個關鍵功能。這才是 REST REST 的真正原因。由于大多數人不使用 HATEOAS，他們實際上是在使用 HTTP RPC，“這是 Reddit 上表達的一些激進觀點。事實上，HATEOAS 是 REST 的最成熟版本。但是，需要比目前通常使用和構建的 API 客戶端更先進、更智能的 API 客戶端是很難實現的。因此，即使是今天真正好的 REST API 也并不總是這樣做。這就是為什么 HATEOAS 主要作為 RESTful API 設計長期發展的愿景。
當服務實現 REST 的某些功能和 RPC 的某些功能時，REST 和 RPC 之間確實可能存在灰色地帶。REST 基于資源或名詞，而不是基于動作或動詞。
以動詞為中心的 RPC 中的操作與以名詞為中心的 REST 中的操作相反
在 REST 中，使用 HTTP 方法完成操作，例如 GET、POST、PUT、DELETE、OPTIONS，希望還有 PATCH。
資料來源：Thomas Davis
分離的客戶端和服務器。REST 盡可能地解耦客戶端和服務器，允許比 RPC 更好的抽象。具有抽象級別的系統能夠封裝其細節，以更好地識別和維持其屬性。這使得 REST API 足夠靈活，可以隨著時間的推移而發展，同時保持系統穩定。
可發現性。?客戶端和服務器之間的通信描述了所有內容，因此不需要外部文檔來了解如何與 REST API 交互。
緩存友好。?重用了大量 HTTP 工具，REST 是唯一允許在 HTTP 級別緩存數據的樣式。相反，在任何其他 API 上實現緩存都需要配置額外的緩存模塊。
支持多種格式。?支持多種格式存儲和交換數據的能力是 REST 目前成為構建公共 API 的普遍選擇的原因之一。
沒有單一的 REST 結構。 構建 REST API 沒有完全正確的方法。如何對資源進行建模以及要對哪些資源進行建模將取決于每個場景。這使得 REST 在理論上簡單，但在實踐中卻很困難。
大有效載荷。 REST 返回大量豐富的元數據，以便客戶端可以從其響應中了解有關應用程序狀態的所有必要信息。對于具有大量帶寬容量的大型網絡管道來說，這種閑聊沒什么大不了的。但情況并非總是如此。這是 Facebook 在 2012 年提出 GraphQL 風格描述的關鍵驅動因素。
過度獲取和獲取不足的問題。 如果包含的數據過多或不足，REST 響應通常會產生對另一個請求的需求。
管理 API。專注于管理系統中對象且面向眾多用戶的API，是最為常見的API類型。REST 幫助這些 API 具有強大的可發現性、良好的文檔，并且它非常適合這個對象模型。
簡單的資源驅動型應用程序。 REST 是一種有價值的方法，用于連接不需要查詢靈活性的資源驅動型應用程序。
它需要對 REST API 進行多次調用，才能返回所需的員工。因此，GraphQL 的發明旨在改變游戲規則。
GraphQL 是一種描述如何發出精確數據請求的語法。對于具有許多相互引用的復雜實體的應用程序數據模型，實現 GraphQL 是值得的。
如何從 GraphQL 端點僅檢索所需的數據，來源：Mohit Tikoo
如今，GraphQL 生態系統正在通過庫和強大的工具（如 Apollo、GraphiQL 和 GraphQL Explorer）進行擴展。
GraphQL 從構建架構開始，架構是您可能在 GraphQL API 中進行的所有查詢以及它們返回的所有類型的描述。架構構建很困難，因為它需要架構定義語言 （SDL） 的強類型。
在查詢之前獲得架構，客戶端可以驗證其查詢，以確保服務器能夠響應它。在到達后端應用程序時，將針對整個架構解釋 GraphQL 操作，并使用前端應用程序的數據進行解析。向服務器發送大規模查詢后，API 會返回包含請求數據結構的 JSON 響應。
GraphQL 中的查詢執行，來源：Jonas Helfer
除了 RESTful CRUD 操作之外，GraphQL 還具有允許來自服務器的實時通知的訂閱。
類型化架構。 GraphQL 提前發布它可以做什么，從而提高其可發現性。通過將客戶端指向 GraphQL API，我們可以找出可用的查詢。
非常適合類似圖形的數據。 數據深入到鏈接關系中，但不適合平面數據。
無版本控制。 版本控制的最佳實踐是根本不對 API 進行版本控制。
REST 提供多個 API 版本，而 GraphQL 使用單個不斷發展的版本，該版本允許持續訪問新功能，并有助于提供更簡潔、更易于維護的服務器代碼。
詳細的錯誤消息。 與 SOAP 類似，GraphQL 提供所發生錯誤的詳細信息。其錯誤消息會涵蓋所有解析程序，并明確指出出錯的具體查詢部分。
靈活的權限。 GraphQL 允許有選擇地公開某些函數，同時保留私有信息。同時，REST 架構不會分批顯示數據。要么全有，要么全無。
性能問題。 GraphQL 以復雜性換取其功能。在一個請求中包含過多的嵌套字段可能會導致系統過載。因此，REST 仍然是復雜查詢的更好選擇。
緩存復雜性。由于 GraphQL 不重用 HTTP 緩存語義，因此它需要自定義緩存工作。
大量的發展前教育。 由于沒有足夠的時間來弄清楚 GraphQL 的利基操作和 SDL，許多項目決定遵循眾所周知的 REST 路徑。
移動 API。 在這種情況下，網絡性能和單條消息負載優化非常重要。因此，GraphQL 為移動設備提供了更高效的數據加載。
復雜的系統和微服務。 GraphQL 能夠將多個系統集成的復雜性隱藏在其 API 后面。它會將來自不同位置的數據進行聚合，形成一個全局性的架構體系。這對于隨著時間的推移而擴展的傳統基礎設施或第三方 API 尤其相關。
每個 API 項目都有不同的要求和需求。通常，架構選擇取決于
了解每種設計風格的所有權衡后，API 設計人員可以選擇最適合項目的設計風格。
RPC 具有緊密耦合功能，適用于內部微服務，但不適用于強大的外部 API 或 API 服務。
SOAP 很麻煩，但其豐富的安全功能對于計費操作、預訂系統和支付仍然是不可替代的。
REST 具有 API 的最高抽象和最佳建模。但它往往在網絡上更重，也更健談 – 如果你在移動設備上工作，這是一個缺點。
GraphQL 在數據獲取方面向前邁進了一大步，但并不是每個人都有足夠的時間和精力來掌握它的竅門。
歸根結底，嘗試一下那些具有特定風格的小型用例是很有意義的，看看它們是否適合您的場景并能解決您的問題。如果是這樣，請嘗試擴展并查看它是否適合更多用例。
原文鏈接：https://www.altexsoft.com/blog/soap-vs-rest-vs-graphql-vs-rpc/
