web services tutorial
このWebサービスのチュートリアルでは、Webサービスのアーキテクチャ、タイプ、およびコンポーネントについて、重要な用語とSOAPとRESTの違いについて説明します。
これで 完全なAPIテストチュートリアルシリーズ 、私たちはすべてを探索しました APIテスト 前のチュートリアルで。このチュートリアルを実行して、WSDLとUDDI、およびそれらがWebサービスを格納および定義する方法を理解してください。
このチュートリアルでは、クライアントアプリケーションが要求を行ったときにWebサービスが内部的にどのように機能するかも説明します。ここでは、SOAPサービスのもう1つの非常に重要な概念であるWSSについても説明します。
学習内容：
Webサービステストの重要な用語
Webサービスの調査を開始する前に、Webサービスのテストで使用される重要な用語を理解しておく必要があります。
はじめましょう！！
＃1）相互運用性
Webサービスは「1つのコードの異なるアプリケーション」をサポートします。これは、異なるプラットフォームにわたるすべてのアプリケーションに対して1つの汎用コードを意味します。
したがって、相互運用性は、複数のアプリケーションが異なるプラットフォーム上にある他のアプリケーションと通信するのを容易にするプロセスです。
＃2）認証と承認
これらは主にSOAPWebサービスで使用されます。一般的に、認証とは何かを検証することを意味し、承認とは何かにアクセスする権利を与える/持つことを意味します。
例えば – Facebookページを持っている場合、Facebookの認証済みユーザーとして扱うことができます。一方、Facebookで私の写真を表示する権利がある場合は、許可されたユーザーです。
これら2つを組み合わせると、「リソースにアクセスできるすべての認証済みユーザーは、それらのリソースの承認済みユーザーと呼ばれます」と言えます。
同じことがWebサービスでも発生します。つまり、トークンの生成に使用されるユーザーIDとパスワードが認証部分をカバーし、Webサーバーへのリクエストの送信に使用されるこのトークンが承認部分をカバーします。
＃3）疎結合アーキテクチャ
Webサービスは、疎結合アーキテクチャに基づいています。これは、Webサービスのインターフェースが本質的に動的（特定のタイムラインでの変更）であることを意味します。ただし、クライアントロジックは、サービスとの対話中に必ずしも変更する必要はありません。
これにより、複数のソフトウェアをより効率的に統合できます。密結合アーキテクチャの場合、インターフェイスが変更されるたびに、クライアントロジックを変更して、サービスと同期させる必要があります。
＃4）アーティファクト
これは、Webサービスで情報またはデータを表すために使用される用語です。これはデータ全体ではなく、URLまたはURI、コンテキストキー、ドキュメントキー、ペイロード、またはサポート画像を含む可能性のある情報の一部です。
＃5）エンドポイント
これは、Webサービスのすべての要求で使用される非常に一般的な用語です。これは、Webサービスのインスタンスにアクセスする完全なURLです。
例えば – https://www.facebook.com/imsaket->これは完全なURLまたはエンドポイントであり、URLとしてfacebook.comがあり、「imsaket」は特定のアドレスを一意に識別するためのコンテキストキーとして渡されます。
最高のメールプロバイダーは誰ですか
＃6）べき等
これはクライアントとサーバーの相互作用であり、サービスのインスタンスに何度ヒットしてもかまいません。サーバーは常に同じ応答をクライアントに返します。
＃7）マーシャリングとデマーシャリング
ご存知のように、カプセル化はOOPSの原則であり、コードとデータを1つにまとめることとして定義されています。同じことがSOAPWebサービスでも発生します。データをペイロード（XML）にラップまたはカプセル化してSOAPメッセージを形成し、それをサーバーに送信する場合、このカプセル化のプロセスはマーシャリングと呼ばれます。
デマーシャリングは、マーシャリングの逆数にすぎません。 SOAPメッセージからデータとコード（XML）をカプセル化解除またはアンラップする方法は、「デマーシャリング」と呼ばれます。
Webサービスとは何ですか？
前に説明したように、Webサービスは、ネットワークを介して1つのマシンから別のマシンにサービスを提供するサービスです。
Webサービスの例： AWS（Amazon Web Services）。これにより、オンラインユーザーはAmazon.comとAmazon.inで販売されているさまざまな商品の価格を表示できます。
Webサービスのコンポーネント
以下に、Webサービスのさまざまなコンポーネントを示します。
＃1）SOAP
Webサービスは、ペイロードまたは要求本文としてXMLを使用するSimple Object Access Protocol（SOAP）を使用します。これは ステートフルプロトコル 特定の種類の操作に独立した方法がないためです。
すべての要求と応答はXMLを介して一度に実行され、GET、PUT、POST、DELETEなどの独立したメソッドは明示的に提供されません。
＃2）WSDL
このSOAPリクエストは Webサービス記述言語（WSDL） これはWebサービスの非常に便利なコンポーネントです。
これは、Webサービスが実際に存在する場所と、特定の要求に対して取得されるWebサービスのタイプを定義します。これは、Webサービス機能を説明するXMLファイルを利用します。
#3) UDDI
もう1つの便利なコンポーネントは UDDI 。これは、Universal Description Discovery andIntegrationの略です。 Webサービスを提供するサービスプロバイダーがあります。したがって、特定のサービスプロバイダーの場合、このUDDIは、それらのWebサービスを記述、検出、および公開するために使用されます。
UDDIは、WSDLのXMLファイルがどこにあるかをクライアントに見つけさせる責任があります（UDDIはWSDLのリポジトリを提供します）。これは、Webサービスが定義および記述される方法です。
＃4）XML-RPC
Extensible Markup Language –RemoteProcedureの略です。 Webサービスのもう1つの非常に重要なコンポーネントは、システム間でメッセージを送信する役割を担うXML –RPCです。リクエストとレスポンスはXML形式であり、HTTPPOSTを介して送受信されます。
XML-RPCの最も優れた機能は、別のプラットフォームにあるクライアントアプリケーションが別のサーバーと通信できることです。 JSON-RPCと呼ばれるものがありますが、これはWebサービスのコンポーネントを形成しないため、記事の後半で説明されています。
Webサービスのアーキテクチャ
Webサービスのアーキテクチャは、次の図に示されています。
すでに知っているように、一般的なWebサービスアーキテクチャは、操作を実行するための3つのエンティティ、つまりクライアント、Webサーバー、およびインターネットで構成されています。操作は、クライアントサーバーアーキテクチャでの要求と応答に他なりません。
クライアントは通常、Webサービスを要求するすべてのアプリケーションまたはソフトウェアシステムのセットであり、それによってWebサービスをサービスコンシューマーにします。
Webサーバーは、Webサービスを提供するすべてのアプリケーションまたはソフトウェアシステムのセットです。すべてのWebサービスは実行するためにネットワークを必要とし、これはインターネットと呼ばれる3番目のエンティティになります。
これは、Webサービスのアーキテクチャの概要にすぎません。
Webサービスの動作図は、以下に示す3つのコンポーネントによって定義されます。
- サービスリクエスター（Find（））
- サービスプロバイダー（Publish（））
- サービスレジストリまたはリポジトリ（Bind（））
これは、SOAPサービスのアーキテクチャで（図で詳細に）説明されています。
.datファイルを開く方法
Webサービスの種類
以下では、2種類のWebサービスについて詳しく説明します。
＃1）SOAPサービス
SOAPサービスはSimpleObject AccessProtocolの略です。 SOAPサービスは、XML言語を使用してエンベロープを形成するステートフルサービスです。 SOAPエンベロープは、2つの部分で記述できます。つまり、1つは SOAPヘッダーと本文 、もう1つは プロトコル SOAPメッセージの送信に使用されます。
このSOAPヘッダーは、アクセスを許可する認証と承認で構成されています。本文は、WSDLを使用してWebサービスを記述する要求のペイロードセクションに含まれ、プロトコルは主にHTTP（HyperText Transmission Protocol）です。
Webサービスセキュリティ
SOAPサービスにはSSL層（Secure Socket Layer）があり、送信中のデータ漏洩を回避する役割を果たし、暗号化と復号化を提供します。
一方、SOAPサービスは、サービスとアプリケーション間の通信中に漏えいがないことを保証するWSS（Web Services Security）も備えているため、より安全です。
javaとc ++の違いは何ですか
ご存知のとおり、すべてのWebサービス（Web APIとは異なり）は、その操作を実行するためにネットワークを必要とします。したがって、Webサービスは、ネットワークに接続するときにセキュリティを提供する必要があります。したがって、Webサービスには、メッセージ転送中のセキュリティ要素をカバーする3つの重要なエンティティがあります。
- 認証と承認 （すでに上で説明しました）。
- 守秘義務： これは、SOAPエンベロープの暗号化と復号化を提供するSSLに完全に依存しています。
- ネットワークセキュリティー： これは、サーバーから取得したすべてのSOAPおよびXML –RPC応答を抽出することを意味します。 例えば、 POSTMANやPARASOFTなどのWebサービスツールを使用する場合、HTTPヘッダーマネージャーの下に、Content-Typeの値を設定するオプションがあることがわかります。値をApplication / JSONに設定して、すべてのRESTを抽出することができます（SOAPサービスはHTTPヘッダーマネージャーオプションをサポートしていないため）。したがって、次のコンテンツタイプを渡すことができます：Application / XML in a ペイロード XML形式でそれ自体。これにより、SOAPとXML-RPCも抽出されます。
これらの3つの要素は、外部からの攻撃に対処するためのWebサービスセキュリティを構成します。
SOAPサービスのアーキテクチャ
すべてのSOAPサービスは、最終的にSOAPサービスのアーキテクチャを形成する3つのエンティティに依存しています。
- サービスプロバイダー： Webサービスの一部または提供するすべてのソフトウェアシステムまたはアプリケーション。
- サービスリクエスター： の一部であるすべてのソフトウェアシステムまたはアプリケーションは、サービスプロバイダーからWebサービスを要求します。
- サービスレジストリ： Webサービスに関するすべての情報がサービスプロバイダーによって提供されるレジストリまたはリポジトリ。 （UDDIですでに説明されています）
説明
これらの3つのエンティティは相互に作用して、Webサービスの実装を成功させます。これは3つのフェーズで行われます。最初のフェーズは Publish（） サービスプロバイダーがサービスレジストリまたはリポジトリ内のWebサービスに関するすべての詳細を提供するフェーズ。
第二段階は Find（） ここで、サービスリクエストは主にクライアントアプリケーションがリポジトリからWebサービスに関する詳細を検索します（WSDL XMLファイルもあります）。最後のフェーズは Binding（） ここで、クライアントアプリケーションまたはサービスリクエスターは、Webサービスの最終的な実装のためにサービスプロバイダーと同期します。
＃2）RESTfulサービス
RESTはRepresentationalState Transferの略で、 ステートレス サービス。
Webサーバーがクライアントセッションに関する情報（クライアントアプリケーションが接続されて実行されるまでの期間）を保存しないため、ステートレスと呼ばれます。つまり、GETなどのREST組み込みメソッドを使用して、各要求タイプを簡単に処理および実行できます。 POST、CUSTOM（PUT）、DELETE、HEADなど。
実際、これらのメソッドはSOAPには存在しません。
メソッドまたは動詞
RESTの各メソッドにはその意味があります。以下に、それぞれについての説明を示します。
- 取得する： このメソッドは、PUTやPOSTなどのメソッドのいずれかを使用してサーバーに送信される情報を取得するために使用されます。これにはリクエスト本文はありません。正常に実行すると、200個の応答オブジェクトが得られます。
- 役職： このメソッドは、リクエスト本文、指定されたURL、ドキュメントキー、コンテキストキーなどを使用してドキュメントまたはレコードを作成するために使用されます。同じものは、GETメソッドを使用して取得できます。正常に実行すると、201応答が返されます。
- プット： これは、POSTMANまたはPARASOFTで使用できるCUSTOMオプションの下にあります。このメソッドは、すでに存在するドキュメントまたはレコードを更新するために使用されます。正常に実行すると、201または200の応答が返されます。
- 削除： このメソッドは、レコードを削除するために使用されます。正常に実行すると、204応答（コンテンツなし）が返されます。
注意： HTTP応答コードは、開発者のコーディング方法によって異なり、場合によっては操作できます。各メソッドタイプから取得する一般的な応答コードをリストしました。
RESTサービスのアーキテクチャ
RESTサービスのアーキテクチャは、サービスコンシューマーまたはリクエスターとサービスプロバイダーの2つのエンティティに依存します。サービスコンシューマーはWebサービスを利用するものであり、サービスプロバイダーはWebサービスを提供するソフトウェアまたはシステムのコレクションです。
通常、サービスコンシューマーであるクライアントアプリケーションは、RESTの組み込みメソッド、URLまたはURI、HTTPバージョン、およびペイロード（メソッドでサポートされている場合）を使用します。
SOAPとREST
これらの2つのタイプのWebサービスは、要求と応答を実行するために使用されますが、操作方法がまったく異なります。
それらの違いは、参照用にリストされています。
- SOAPエンベロープはRESTで使用できますが、その逆はできません。 例えば。 SOAPで作成されたユーザートークンは、HTTPヘッダーマネージャー->承認の下のRESTリクエストで渡すことができます。
- SOAPサービスはSSLとは別にWSSを提供するため、SOAPは通常RESTサービスよりも安全です。このSSLは、SOAPとRESTの両方に存在します。
- XMLデータ形式のためにSOAPでの要求処理に時間がかかるため、SOAPはRESTよりも低速です。 RESTはJSONを使用します。これは非常に軽量であるため、高速になります。
- SOAPには組み込みメソッドはありませんが、RESTにはGET、PUT、POSTなどがあります。
- SOAPはステートフルですが、RESTはステートレスです。
- SOAPの要求および応答本文は、XMLデータ形式のみをサポートします。 RESTでは、リクエストとレスポンスの本文は、JSON、XML、プレーンテキストなどの多くのデータ形式をサポートしています。
結論
このWebサービスのチュートリアルでは、Webサービスのアーキテクチャ、コンポーネント、およびタイプについて説明しました。
また、SOAPサービスとRESTサービスの違い、およびWebサービスに関連するその他の重要な概念と用語についても学びました。
このチュートリアルがWebサービスの理解に役立つことを願っています!!