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