SOAP と REST API: Web サービスの違い

SOAPとRESTの違い

それぞれの手法には独自の長所と短所があります。 したがって、各デザインがどのような状況で使用されるべきかを理解することは常に良いことです。 この REST と SOAP API の違いのチュートリアルでは、REST と SOAP API の主な違いと、それらの使用中に発生する可能性のある課題について説明します。
SOAP と REST API の主な違いは次のとおりです。

<?xml version="1.0"?>
<SOAP-ENV:Envelope 
xmlns:SOAP-ENV
="http://www.w3.org/2001/12/soap-envelope" 
SOAP-ENV:encodingStyle
=" http://www.w3.org/2001/12/soap-encoding">
<soap:Body>
 <Demo.guru99WebService
 xmlns="http://tempuri.org/">
   <EmployeeID>int</EmployeeID>
   </Demo.guru99WebService>
 </soap:Body>
</SOAP-ENV:Envelope>

{"city":"Mumbai","state":"Maharastra"}

いつRESTを使用しますか？

最も議論の余地のあるトピックの XNUMX つは、Web サービスの設計中に REST をいつ使用する必要があるのか​​、または SOAP をいつ使用する必要があるのか​​ということです。 以下は、Web サービスに REST および SOAP API テクノロジーをいつ使用するかを決定する重要な要素の一部です。 RESTサービスは次の場合に使用する必要があります

• 限られたリソースと帯域幅 – SOAP メッセージは内容が重く、はるかに多くの帯域幅を消費するため、ネットワーク帯域幅に制約がある場合は REST を使用する必要があります。
• 無国籍 – あるリクエストから別のリクエストまで情報の状態を維持する必要がない場合は、REST を使用する必要があります。 あるリクエストからの一部の情報が別のリクエストに流れる必要がある適切な情報フローが必要な場合は、SOAP がその目的により適しています。 あらゆるオンライン購入サイトを例に挙げてみましょう。 これらのサイトでは通常、ユーザーはまず購入する必要のある商品をカートに追加する必要があります。 購入を完了するために、カートのすべてのアイテムが支払いページに転送されます。 これは状態機能を必要とするアプリケーションの例です。 さらに処理するには、カート項目の状態を支払いページに転送する必要があります。
• キャッシング – 大量のリクエストをキャッシュする必要がある場合は、REST が最適なソリューションです。 場合によっては、クライアントが同じリソースを複数回要求することがあります。 これにより、サーバーに送信されるリクエストの数が増加する可能性があります。 キャッシュを実装すると、最も頻繁に実行されるクエリの結果を中間の場所に保存できます。 したがって、クライアントがリソースを要求するたびに、最初にキャッシュがチェックされます。 リソースが存在する場合、サーバーには進みません。 したがって、キャッシュは、Web サーバーへのアクセスの量を最小限に抑えるのに役立ちます。
• コーディングの容易さ – REST サービスのコーディングとその後の実装は、SOAP よりもはるかに簡単です。 したがって、Web サービスに即効性のあるソリューションが必要な場合は、REST が最適です。

次に、この SOAP と REST の違いのチュートリアルでは、SOAP API をいつ使用するかを学習します。

いつSOAPを使用しますか？

SOAPは次の場合に使用する必要があります

1. 非同期処理とその後の呼び出し – クライアントが保証されたレベルの信頼性とセキュリティを必要とするという要件がある場合、新しい SOAP 標準である SOAP 1.2 は、特にセキュリティに関して多くの追加機能を提供します。
2. 正式なコミュニケーション手段 – クライアントとサーバーの両方が交換形式について合意している場合、SOAP 1.2 はこのタイプの対話に対して厳格な仕様を提供します。 例としては、支払いが行われる前にユーザーがカートに商品を追加するオンライン購入サイトがあります。 最終的な支払いを行う Web サービスがあると仮定しましょう。 Web サービスがカートの品目名、単価、および数量のみを受け入れるという確固たる合意が得られる場合があります。 このようなシナリオが存在する場合は、常に SOAP プロトコルを使用することをお勧めします。
3. ステートフルオペレーション – アプリケーションに、あるリクエストから別のリクエストまで状態を維持する必要があるという要件がある場合、SOAP 1.2 標準はそのような要件をサポートする WS* 構造を提供します。

次に、REST と SOAP API の違いで、SOAP API の課題について学びます。

SOAPAPIの課題

API は、 アプリケーションプログラミングインターフェース クライアントとサーバーの両方によって提供されます。 クライアントの世界では、これはブラウザによって提供されますが、サーバーの世界では、SOAP または REST のいずれかである Web サービスによって提供されます。

SOAP API の課題

1. WSDL ファイル – SOAP API の主な課題の 1 つは、WSDL ドキュメント自体です。WSDL ドキュメントは、Web サービスで実行できるすべての操作をクライアントに伝えるものです。WSDL ドキュメントには、SOAP メッセージで使用されるデータ型や、Web サービスで使用できるすべての操作など、すべての情報が含まれます。以下のコード スニペットは、サンプル WSDL ファイルの一部です。

<?xml version="1.0"?>
<definitions name="Tutorial"             
	targetNamespace=https://demo.guru99.com/Tutorial.wsdl             
	xmlns:tns=https://demo.guru99.com/Tutorial.wsdl             
	xmlns:xsd1=https://demo.guru99.com/Tutorial.xsd            
	xmlns:soap=http://schemas.xmlsoap.org/wsdl/soap/
	xmlns="http://schemas.xmlsoap.org/wsdl/"> 

	<types>  
		<schema targetNamespace=https://Demo.guru99.com/Tutorial.xsd
		xmlns="http://www.w3.org/2000/10/XMLSchema">

      	<element name="TutorialNameRequest">    
			<complexType>          
				<all>           
					<element name="TutorialName" type="string"/>         
				</all>       
			</complexType>    
		</element>     
	<element name="TutorialIDRequest">        
		<complexType>          
			<all>           
				<element name="TutorialID" type="number"/>         
			</all>       
		</complexType>      
	</element>   
	</schema>  
</types>	

上記の WSDL ファイルのように、TutorialNameRequest 要素の一部である String 型の「TutorialName」という要素があります。

さて、WSDLファイルがビジネス要件に従って変更され、TutorialNameがTutorialになる必要があるとします。Descriptつまり、現在この Web サービスに接続しているすべてのクライアントは、WSDL ファイルの変更に対応するために、コードに対応する変更を加える必要があります。

これは、WSDL ファイルの最大の課題がクライアントとサーバー間の緊密な契約であり、XNUMX つの変更がクライアント アプリケーション全体に大きな影響を与える可能性があることを示しています。

2. ドキュメント サイズ – もう XNUMX つの重要な課題は、クライアントからサーバーに転送される SOAP メッセージのサイズです。 メッセージが大きいため、帯域幅に制約がある場所で SOAP を使用すると、大きな問題になる可能性があります。

次に、RESTful と SOAP の違いで、REST API の課題について学びます。

RESTAPIの課題

1. セキュリティの欠如 – REST は、SOAP のようなセキュリティを課しません。 これが、REST がパブリックに利用可能な URL に非常に適している理由ですが、クライアントとサーバー間で受け渡される機密データに関して言えば、REST は Web サービスに使用するには最悪のメカニズムです。
2. 状態の欠如 – ほとんどの Web アプリケーションにはステートフル メカニズムが必要です。 たとえば、ショッピング カートの仕組みを備えた購入サイトの場合、実際に購入する前にショッピング カート内の商品の数を把握する必要があります。 残念ながら、この状態を維持する負担はクライアントにあり、クライアント アプリケーションが重くなり、維持が困難になるだけです。

SOAPとCORBAとDCOMとの違い Java RMI

RPC (リモートプロシージャコール) メソッドは、SOAP と REST API が登場する前に一般的に使用されていました。 利用可能なさまざまなリモート アクセス技術については、以下で説明します。

1. CORBA – これはとして知られていました Cオムモン Oジェクト R探求 Bローカー Aアーキテクチャ。このシステムは、さまざまなプラットフォームで構築されたアプリケーションが相互に通信できるようにするために導入されました。CORBA はオブジェクト指向アーキテクチャに基づいていますが、呼び出し側のアプリケーションがこのアーキテクチャに基づいている必要はありませんでした。この手法の主な欠点は、インターフェイス定義言語と呼ばれる別の言語で開発する必要があることであり、開発者が CORBA システムを利用するために習得しなければならない追加の言語が提供されるだけでした。
2. DCOM - これは D配布 Cオポネント Oジェクト Model、これは独自の Microsoft クライアントがリモート コンポーネントにアクセスするためのテクノロジー。このメカニズムの最大の問題は、不要になったリソースを解放するのがクライアント アプリケーションの責任であることです。第二に、クライアントがリクエストを送信するときに、そのリクエストが正しい形式でラップまたはマーシャリングされていることを確認するのはクライアントの責任でした。 Web サービスが送信されたリクエストを理解できるようにするためです。もう XNUMX つの問題は、クライアント アプリケーションが Java DCOM を動作させる必要があるベースのアプリケーション (Microsoft テクノロジ)、他のプログラミング言語で構築されたアプリケーションが DCOM ベースの Web サービスで動作できるようにするには、追加のコーディングが必要でした。
3. Java RMI - として知られている Java R破ったと宣言 M方法 I召喚、これは Java リモートオブジェクトをリモートプロシージャコールで呼び出す方法の実装。この技術の最大の制約は、 Java RMIは、 Java 仮想マシン。つまり、呼び出しアプリケーションも仮想マシン上で実行する必要がある。 Java 活用するための枠組み Java ＲＭＩ。

SOAP とこれらの技術の主な違いは次のとおりです。

1. HTTP 経由での作業 – すべての RPC 技術には 1 つの大きな制限があり、それは HTTP プロトコルでは動作しないということです。Web 上のすべてのアプリケーションはこのプロトコルで動作する必要があったため、これは RPC スタイルの Web サービスにアクセスするクライアントにとって大きな障害となっていました。
2. 非標準ポートの使用 – RPC スタイルの Web サービスは HTTP プロトコルでは機能しないため、クライアントがこれらの Web サービスの機能にアクセスするには、別のポートを開く必要がありました。