SOAP和REST，也許您已經很熟悉它們，希望擴展您的知識或獲取新的觀點。或者，也許您聽說過它們，并正在尋求更好的理解。畢竟，SOAP和REST已建立完善，其定義和規范可以追溯到幾十年前。
請允許我幫助描述，比較以及以其他方式闡明這兩種重要的Web服務和Web API設計方法。我還將重點介紹與這些方法相關的一些測試挑戰以及如何解決它們。首先，讓我們定義它們是什么以及它們與萬維網的關系。
簡介
萬維網聯盟（W3C）為全球范圍內的互連資源（我們稱為萬維網）推薦了標準和協議。在“Web”地址訪問“Web”資源，并通過“Web”協議進行傳遞。
當有人閱讀此博客文章時，您可能知道您正在閱讀瀏覽器地址欄中顯示的URI上的HTML文檔，該文檔是使用HTTP（S）協議請求并發送的。W3C定義了使您能夠閱讀此博客文章的相同技術如何促進軟件系統之間的通信。特別是，W3C定義了“Web服務”，這導致了多年來的許多其他標準和技術的創建。讓我們從高層次看一下它們是什么。
SOAP
|
簡單對象訪問協議（SOAP Simple Object Access Protocol）是一種面向對象的協議，通過該協議，對象在客戶端和服務器之間進行交換，并與XML進行串行化。SOAP規范建立在W3C定義的其他“Web”技術之上，包括XML和HTTP。許多規范都基于或擴展了SOAP規范，包括一些不是那么“簡單”的規范。SOAP服務與SOAP客戶端交換SOAP消息。SOAP消息也稱為“信封”。SOAP信封有一個“Body”元素和一個可選的“Header”元素。“正文”通常會包裝或從字面上“包圍”另一個XML文檔。SOAP請求還指示正在調用的操作或動作。不同的操作接受并返回不同類型的文檔。
|
REST
|
代表性狀態轉移。與SOAP不同，REST不是一種特定的技術，而是一種體系結構樣式，它定義了軟件系統的特定約束。符合REST的Web服務或Web API通常被稱為RESTful API或REST API。REST API的目的是交換資源的表示形式。資源可以是可以在概念上由URI標識的任何種類的實體。REST API偵聽帶有子路徑的基本URI，以訪問API公開的每個資源。資源路徑可以包括一個或多個可用于標識資源的參數，其中某些路徑段可能包含標識符。資源參數也可以采用查詢參數或標頭的形式。REST API公開了一個或多個CRUD操作以檢索或操縱資源（創建、檢索、更新和刪除）。
|
現在，讓我們深入研究一些細節，了解這些方法之間的比較。
運作方式
SOAP服務定義了一組操作。這些操作可以是任意的，因為所定義的操作的范圍或目的沒有限制。操作具有簽名，通常代表信封的Body元素中元素的完全限定名稱。例如，元素的名稱可能是“calculateSomething”或“doSomethingFun”。
REST API對每個資源都有一組操作。可用的操作僅限于CRUD（創建、檢索、更新和刪除）。這些操作映射到HTTP方法，例如GET，POST，PUT，PATCH和DELETE。
基礎對比
SOAP
|
SOAP操作提供了更高的靈活性，因為它們不僅限于CRUD，而且不必圍繞諸如REST之類的特定資源類型進行構造。但是，操作也可以用于CRUD，其中SOAP主體中的XML可以包括對象的XML表示及其標識符。
|
REST
|
REST操作提供了更高的簡便性。URI用于標識資源，該資源與正在交換的資源的表示形式分離。另外，操作必須是無狀態的，這意味著這些操作以一致的方式運行，而不是基于客戶端和服務端點之間的會話狀態。
|
關鍵對比
SOAP
|
通過支持任意操作并可能跟蹤狀態，SOAP服務可以具有更高的復雜性。一個示例可以是具有“addToCart”操作的書店服務。每當客戶致電“addToCart”時，服務就會跟蹤客戶購物車中的商品。其他客戶可以調用“addToCart”，而不會影響其他客戶的購物車。該服務分別跟蹤每個客戶端的狀態。
|
REST
|
通過將操作限制在CRUD上，REST API比SOAP更受限制。另外，客戶有跟蹤自己狀態的負擔。在書店示例中，客戶需要知道其購物車的ID，以便它可以為其購物車構建正確的URI，例如“cart/{id}”。客戶端可以在該URI上執行GET來獲取其購物車的結構化表示。客戶端也可以在相同的URI上執行PUT，以使用更新的表示形式更新其購物車。
|
數據表示
SOAP消息傳遞涉及稱為SOAP信封的XML文檔的交換。SOAP信封包含一個“Body”元素和一個可選的“Header”元素。“Body”元素中的XML可以是任意的，但通常表示一個或多個實體或對象。內容類型是“text/xml”還是“application/soap+xml”，具體取決于是否遵循SOAP版本1.1或SOAP版本1.2。SOAP中的XML元素還可以用于包裝其他類型的數據（文本或二進制）。W3C定義的稱為“XOP”和“MTOM”的方法描述了如何將XML和SOAP消息中的二進制數據有效地打包為MIME“Multipart/Related”，從而避免了直接在XML標簽中對二進制數據進行base64編碼的需求。
REST API消息傳遞涉及資源表示形式的交換。“表示”可以是任何數據格式。它可以是結構化的數據交換/交換格式，例如XML或JSON，也可以是完全不同的格式，例如PDF或JPEG。沒有內容類型限制。REST API可以支持多種數據格式或針對不同資源的不同數據格式。
基礎對比
SOAP
|
XML是標準化的且易于理解，由各種W3C建議定義。XML具有名稱空間的概念，該名稱空間有助于消除元素歧義，避免命名沖突。SOAP信封提供了一層封裝，使“Header”元素下可以包含其他元數據。
|
REST
|
REST API可以使用的數據格式不受限制。對于結構化數據，JSON的使用很普遍，并且使用和生成的速度比XML快得多。但是，還有其他序列化結構化數據的格式比JSON更為緊湊和高效，例如BSON（二進制JSON）或Google的協議緩沖區（Protobuf）。任何內容類型都是可能的。
|
關鍵對比
SOAP
|
與其他數據格式相比，XML也可能變得冗長或腫，同時產生和使用的序列化成本相對較高。但是，可以使用諸如“Content-Encoding: gzip”HTTP壓縮方案之類的壓縮來減小消息大小。通過使用替代或二進制XML編碼，例如Microsoft的XML .NET Binary Format，可以降低序列化成本。
|
REST
|
REST API沒有標準的數據交換格式。因此，您可能需要一組不同的庫來使用和產生結構化數據，具體取決于要與之通信的REST API。但是，JSON非常流行并且經常可用。
|
可擴展性
SOAP和REST是可擴展的，但是方式非常不同。讓我們深入比較一下。
基礎對比
SOAP
|
協議綁定不必是HTTP，而可以是任何東西。SOAP消息可以通過其他一些基于TCP的協議（例如SMTP）發送，也可以通過UDP套接字發送，就像WS-Discovery和UPnP一樣。微軟的.NET WCF SOAP框架具有TCP和命名管道傳輸。諸如JMS（Java消息服務）或AMQP（高級消息隊列協議）之類的事件驅動或消息排隊接口也用于SOAP。
SOAP還允許使用不同的消息交換模式。它不必是請求答復的。它可以是異步的，單向的或一勞永逸的。SOAP用于面向服務的體系結構（SOA），其中服務被松散耦合、推送或響應企業服務總線（ESB）路由的消息。
|
REST
|
REST API是可擴展的，因為它們可能表示具有不同消息格式的資源。與SOAP不同，您不僅限于基于XML的表示形式。可以添加新資源而不影響現有資源。可以通過將某些版本號或版本標識符作為URI的一部分來對REST API進行版本控制。
|
關鍵對比
SOAP
|
具有更高可擴展性帶來了更大的復雜性。考慮到可能使用的各種協議，消息傳遞模式和WS-*規范，沒有唯一的方法來實現SOAP消息傳遞。
|
REST
|
REST API通常僅限于HTTP，其中方法和資源URI在HTTP請求標頭中發送。但是，RESTful方法已經通過諸如約束應用協議（CoAP）之類的其他技術完成，該技術是針對物聯網應用程序約束環境的REST實現。RESTful主體也可以在RabbitMQ和MQTT之類的消息傳遞代理中遵循，其中資源標識符和CRUD操作可以潛在地映射到消息目標或“主題”。
|
互通性
遵循開放標準，在設計SOAP時考慮到了互操作性，并不局限于任何特定的實現，平臺或編程語言。但是，規范中的某些內容尚待解釋。有些部分可能令人困惑，或者有錯誤、錯別字或不良示例。這些問題源于簡單的事情，例如：
-
是否應將特定值括在引號中。
-
某些XML構造是否可行還是應該避免。
-
SOAP主體中是否應允許或限制某些類型的事物。
另一個標準機構Web服務互操作性組織（WS-I）即將提供Web服務互操作性的準則。WS-I提供了各種互操作性配置文件。每個概要文件都有一個需求列表和一個斷言列表，它們定義了如何檢查需求。簡而言之，WS-I概要文件說諸如“您應該這樣做”和“您不應該那樣做”之類的事情。有趣的事實：Parasoft是WS-I基本配置文件1.1測試斷言文檔（TAD）的撰稿人。
REST API可互操作，因為它們易于調用。有許多工具和API可以發出HTTP請求。流行的工具包括cURL和Postman。甚至網頁上的簡單表單都可以用來發出HTTP請求。除HTTP之外，REST API還通常使用各種開放標準，包括JSON之類的開放消息格式。REST API還可以實現各種開放性標準，以實現安全性和授權（稍后會詳細介紹）。
基礎對比
SOAP
|
SOAP在設計時就考慮了互操作性。W3C SOAP規范主要由Microsoft編寫，Microsoft擁有自己的SOAP堆棧，該堆棧是作為Microsoft .NET Framework（最初是.NET Web服務增強（WSE）和后來的.NET Windows Communication Foundation（WCF））的一部分實現的。但是，可以從許多其他供應商處獲得SOAP堆棧，包括像Apache項目這樣的開源項目。除了.NET之外，SOAP堆棧也可用于不同的平臺和編程語言，例如java，python和typescript。如果遵循相同的一組開放SOAP標準，則使用不同SOAP堆棧實現的SOAP客戶端和SOAP服務就可以通信。
|
REST
|
REST API遵循KISS（“保持簡單、愚蠢”）原則，遵循REST軟件體系結構的一般設計原則。REST API易于調用，不一定需要復雜的軟件堆棧，就像您通常需要與SOAP端點進行通信一樣。
|
關鍵對比
SOAP
|
SOAP有許多擴展，通常稱為WS-*。有WS-Addressing，WS-Policy，WS-Discovery，WS-MetadataExchange，WS-SecureConversation，WS-SecurityPolicy，WS-Trust，WS-Federation。WS-Security還具有各種相關規范，包括與XML和SOAP簽名，XML和SOAP加密以及SAML（安全斷言標記語言）相關的規范。清單不停地不斷。SOAP服務很可能會遵循幾種WS-*規范，從而增加了最初定義為“簡單”協議的復雜性。您的客戶必須遵循與該服務相同的WS-*標準，否則他們將無法正確通信。
|
REST
|
REST API不一定必須遵循開放標準。盡管JSON非常流行，但是沒有標準的數據交換格式。任何內容類型都是可能的，包括可能的專有數據格式。此外，某些安全性或授權框架可能會帶來額外的復雜性，需要在客戶端進行兼容的實現。
|
安全性
安全性是SOAP和REST的重要考慮因素。當通過有線發送消息時，需要傳輸層安全性來對消息進行加密，以防止竊聽。消息層安全性對于完整的端到端安全性是必不可少的，因此可以保護消息免受任何可能在到達目標位置之前對其進行訪問的中介的攻擊。需要身份驗證或授權機制才能在客戶端和服務器之間建立身份。
基礎對比
SOAP
|
SOAP有大量的安全規范，稱為WS-Security，由標準組織OASIS發布。除了HTTPS之類的傳輸層安全性機制之外，WS-Security規范還描述了如何將安全性直接嵌入SOAP消息本身（包括簽名、加密數據）中，以及如何打包安全性令牌以建立諸如SAML（安全性聲明標記語言）之類的身份。
|
REST
|
REST可以利用HTTP中的現有機制來實現安全性，包括SSL和基于HTTP的身份驗證方案。還有一些開放的授權標準，包括OpenID Connect（OIDC），它基于OAuth和其他一些開放規范，例如JSON Web令牌（JWT）。
|
關鍵對比
SOAP
|
OASIS WS-Security規范很復雜。實現多個WS-Security和其他WS-*規范的服務給構建客戶端帶來了挑戰。我需要什么鑰匙？我是否需要對消息進行簽名或加密？我應該使用哪種XML規范化算法？我是否需要首先獲取SAML令牌并將其包含在SOAP標頭中？我需要對消息的哪些部分進行簽名和加密？
|
REST
|
消息層安全性不是標準的，有些是專有的。例如，Amazon AWS提供了服務器端和客戶端機制來加密發送到其API或從其API發送的消息。
|
服務定義
SOAP服務和REST有多種類型的機器消耗性文檔格式。服務定義文檔支持自動化處理，例如為客戶端或服務存根自動生成代碼。服務定義文檔也可以翻譯成人類友好的文檔格式，例如網頁。
基礎對比
SOAP
|
SOAP服務由WSDL描述，WSDL是W3C的另一個開放規范。WSDL是XML文檔。它定義了用于請求、回復和故障消息的服務端點、操作和XML模式。
|
REST
|
REST API有多種服務定義格式。其中包括OpenAPI，RAML，API藍圖和WADL。它們都提供了不同的方式來描述REST API共有的事物，例如資源路徑、參數、操作以及表示的類型和格式或模式。OpenAPI基于JSON Schema規范，可以表示為JSON或YAML。RAML文檔基于YAML并支持JSON Schema和XML Schema（XSD）。API藍圖基于對象表示法的Markdown語法（MSON），并支持JSON模式。WADL是基于XML的W3C提交，支持使用XML Schema描述XML表示形式，這有點類似于WSDL for SOAP。
|
關鍵對比
SOAP
|
WSDL規范存在一些問題，這些問題由Web服務互操作性組織（WS-I）提供額外的說明和互操作性建議。WSDL也有多個版本。WSDL 1.1是最常實現的。WSDL 2.0（以前稱為WSDL 1.2）未被包括Microsoft的.NET WCF在內的所有SOAP堆棧采用。有趣的是，WSDL 2.0引入了對描述REST API的支持。
|
REST
|
REST API沒有標準的服務定義格式。但是，OpenAPI是作為標準的緊密考慮因素。OpenAPI最初由SmartBear開發為“Swagger”，后來以OpenAPI的形式捐贈給Linux基金會。該規范由OpenAPI Initiative監督，該組織的成員來自Google，IBM和Microsoft等大型公司。
|
每種服務定義格式都有其自己的代碼和文檔生成工具集合。這意味著您需要根據服務實現使用不同的工具集。但是，存在轉換器，因此您可以將OpenAPI文檔轉換為RAML（反之亦然）。
我應該如何測試所有這些？
REST和SOAP提供了自己獨特的權衡和挑戰，尤其是在測試方面。要測試API，您需要能夠構建客戶端，發送輸入數據，然后能夠查看和驗證返回的輸出。
基礎對比
SOAP
|
WSDL文檔可以提供SOAP服務的完整描述，包括其安全要求。有各種可用的商業和開源工具，它們可以使用WSDL文檔來自動生成用于測試SOAP端點的客戶端。一個簡單的示例是Microsoft的WCF測試客戶端應用程序。
|
REST
|
REST API可以類似地提供服務定義文檔，可以使用該文檔來生成測試客戶端。對于OpenAPI，Swagger UI提供了一個簡單的Web界面來“試用”該API公開的每個操作。
|
關鍵對比
SOAP
|
SOAP服務可以使用HTTP以外的協議來實現，其中通信可能需要特定的消息傳遞接口（例如JMS）。各種WS-*協議都很復雜。免費和開源工具具有局限性，并且缺乏對所有傳輸和WS-*協議的支持。但是，Parasoft SOAtest通過全面支持SOAP和相關協議來幫助解決此問題。
|
REST
|
REST服務不一定具有服務定義。手動構建客戶端可能很困難且繁瑣，需要確定正確的API調用順序以將它們串在一起以創建所需的場景。但是，Parasoft SOAtest可幫助解決此問題。除了能夠從各種服務定義格式創建測試客戶端之外，SOAtest的Smart API Test Generator還可以通過監視API調用并使用人工智能自動構建和配置測試方案來自動執行API測試創建。
|
你還在為此頭疼嗎？讓Parasoft幫助。借助完整的端到端API測試解決方案Parasoft SOAtest，降低測試服務接口的成本、時間和復雜性。無論是SOAP，REST還是其他服務接口或技術，SOAtest都能滿足您的要求。
不僅限于SOAP和REST？查看我們的“測試微服務”白皮書，以了解有關面向服務的體系結構的現代方法的更多信息。
標簽：
本站文章除注明轉載外，均為本站原創或翻譯。歡迎任何形式的轉載，但請務必注明出處、不得修改原文相關鏈接，如果存在內容上的異議請郵件反饋至chenjj@fc6vip.cn
金喜正規買球 
108次
相關產品
正式授權
最新文章 
金喜正規買球相關的文章 
微信
在線咨詢
渝公網安備
50010702500608號
客服熱線