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