はじめに
時々、さまざまなWebサービスに直面したとき、「なぜそんなに複雑だったのか」という質問を自問します。 開発プロセス、コードの清潔さ、テスト、方法論に多くの注意を払っています。 コメントを作成し、ドキュメントを作成します。 しかし、同時に、基本的な外部システムインターフェイスであるWebサービスにはあまり注意を払っていません。
以下のすべては、さまざまなタイプのWebサービスに起因する可能性がありますが、基本的にはSOAP Webサービスについて説明します。
使用する
今日の世界では、Webサービスはどこでも使用されています。 毎日、誰かが世界中のAPIを使い果たしています。 ドキュメントを公開し、訪問者の流入を待っています。
サービス別に、ユーザーは天気を調べ、交通情報を取得し、最新のニュースを読み、イベントについて調べます。 facebook、twitter、vk、googleなどのすべてのソーシャルプロジェクト、ユーザーへのWebサービスへのオープンアクセス。 すぐに多くの便利なクライアントプログラムがあります。 人はいつでもどこでも自分の感情や考えを共有できると誰が考えたでしょう。
ますます多くの政府サービスが同じサービスを取得しています。 彼らのために、罰金を支払い、貴重な情報を受け取り、アプリケーションを書き、サービスを受けることができます。
サービスは、私たちを取り巻く情報システムをますます接続しています。
バラエティ
サービスの実装の基礎となるテクノロジーは非常に多様です。 レストサービス、石鹸、暗号化、さまざまなデータ転送プロトコル、データ圧縮技術、同期/非同期データ転送、保証付き配信があります。
これらはすべて、さまざまなバージョンのテクノロジーとサービスによって悪化しています。 互換性のあるシステムを作成するには、多くの努力をする必要があります。
誰が森の中にいて、誰が...
しかし、この多様性をすべて使用する方法は？ ここでは意見が異なります。 しかし、実際には、多くのサービスはそうではないと言うことができます。 これを確認する最も簡単な方法は、一連のステートメントを使用することです。
次の場合、これはWebサービスです。
- そのために、ほとんどの一般的な言語（java、.net、python、ruby、c ++など）で自動化された手段で自給自足のクラスを作成できます。
- 追加のドキュメントは必要ありません。
- それを使用するには、追加の操作は必要ありません（telnetを介してポートを開く、自分に回線をアップロードするなど）。
- 一般的に受け入れられている技術のみが使用されます。
- サービスインターフェイス全体がそれ自体で記述されています（wsdl、xsd）。 タイプなし。 すべてのタイプは正確に定義されています。
- 名前空間を使用して定義されたすべてのタイプ
- MTOMはデータ圧縮に使用されます。
- 保証された配信、承認などの標準ヘッダーが使用されます。
- UTFエンコーディングと、タイプの説明にキリル文字およびその他の文字は含まれません
次の場合、これはサービスではありません。
- サービスを使用するには追加情報が必要です。
- Wsdlおよびxsdは、サービスインターフェイスを完全には記述していません。
- 使用されるすべてのタイプ
- メッセージルーティングは、soap-actionを使用して行われます
- データを圧縮するには、zipを使用します
- 添付ファイルはグループ化され、1つの要素にパッケージ化されます。
- 無効または未定義の名前空間
- サービスが自動化された手段でクラスを作成することはできません
- このサービスを使用するには、追加のコード（データパッケージなど）を記述する必要があります
- リクエストが重複した情報を送信する場合（リクエストの4つの3つの場所に名前を書く）
- リクエストは、情報を取得するという観点からは不要なオプションの属性（システム属性など）を入力する必要があります（「この属性でこれを送信しないと、システムはリクエストを認識しません」）。
- ほとんどのクライアントでサポートされていない形式を使用します。
- 情報を取得するには、1つのプロバイダーのフレームワーク内でいくつかの要求を行う必要があります（「まず、ここからこの行を取得し、次にここで要求を行います...」）
- 1つのサービスへの要求に対して異なる回答（異なる応答形式）を受信できます
- サービスには、すべての要求に使用される複雑な構造があります。 1つの汎用エントリポイントよりも10の単純なエントリポイントを使用する方が適切です。
- 利用可能な二重目的属性
- システム情報は、ヘッダーではなくメッセージの本文で送信されます。 メッセージの本文には、リクエストデータのみを含める必要があります。
- 非標準ヘッダーは、認証、ルーティング、配信保証に使用されます。
単一のエントリポイント
適切に設計されたサービスは自給自足です。 彼自身が独自に解釈したインターフェースについて説明しています。 彼にとっては、クラスを作成するだけですぐに使い始めることができます。 クライアントコードでは、リクエスト属性の入力のみが実行され、追加の操作は行われません。 サービスのデータ構造はシンプルで簡単です。
すべてはコードと同じです。 最小のネストレベル、自己文書化可能性、要素および型の論理名のシステム（答えのSampleRequestは衝撃的です...）。
これらの要件を満たさないすべてのサービスは、模倣としか呼べません。 もちろん、これらは似ていますが、誰もサービスを使用できない場合、これはデータプロバイダーの問題です。
圧縮または最適化
ここですべてが発明されました。 base64を渡します。 多すぎる？ 次に、MTOMを使用します。 まだたくさん？ ギガバイトはWebサービスで転送されません、目を覚まします！ 高速ファイルストレージへのリンクを渡します。 クライアントが写真、ドキュメント、アーカイブ、その他のメディア情報を必要とする場合、クライアントはそれをダウンロードします。 彼は、リクエストごとに20メガバイトの追加の負荷を必要としません。 サービスはテキスト情報を送信しますが、それ以外はすべて送信するのが合理的ではありません。
会社が製品を使用しない場合、費用はかかりません
サービスプロバイダー自体がそれを使用しない場合、特別な相互作用ルールを使用する場合、ルールに特定の特権を導入する場合、定義上、このサービスを使用することはできません。 サプライヤは、彼自身が対応できない不可解なサービスを作成しました。 あなたは悲しみなしにそのようなサービスを見ることができません...
おわりに
そのようなサービスはどこで見つけましたか？ はい、どこにでもあります！ 大規模なプレーヤーでさえ、理解できない技術的解決策を持っています。 適切に構築されたサービスによってのみ、多くの異種システムの高度な統合と安定性を実現できます。