1. 序章

API（Application Programming Interface）は、要求を受け取り、応答で応答するソフトウェアの一部です。 これにより、複数のソフトウェアコンポーネントが相互に通信できるようになります。 今日、APIは、アプリケーション、特にWebおよびモバイルアプリケーションを開発する際に重要です。

このチュートリアルでは、RESTおよびSOAPと呼ばれるAPIを構築するための2つの最もよく知られているアプローチを分析します。

2. 休み

REST（REpresentational State Transfer）は、APIを作成するためのアーキテクチャ上のスタイルです。簡単に言うと、スケーラブルで信頼性が高く、保守可能なWebサービスを開発するための一連の優れたプラクティスです。 REST規則に従うアプリケーションは、RESTfulと呼ばれます。 RESTは標準ではないということは重要です。 APIの機能を開発する際に柔軟性を提供します。

RESTは、 HTTP 、SMTP、FTPなどのさまざまなプロトコルで動作します。 さらに、 JSON 、 XML 、HTMLなど、さまざまな形式を使用してデータを転送できます。 ただし、ほとんどの場合、RESTfulWebサービスはHTTPおよびJSONで動作します。 他の構成のアプリケーションは一般的ではありません。

前述したように、RESTは調整可能です。 APIがRESTfulと呼ばれるために従わなければならない一連のガイドラインがあります。 それらについて説明しましょう。

2.1. コアコンセプト

まず、RESTfulAPIはクライアントサーバーの制約に従う必要があります。 スケーラビリティと移植性を提供します。 したがって、クライアント側は新しいプラットフォームで簡単に拡張できます。 つまり、複数のクライアントアプリケーションが単一のAPIを使用して、データの一貫性を維持できます。

第二に、 RestfulAPIはステートレスである必要があります。 サーバーは、ユーザーのセッションまたは中間状態に関する情報を保存できません。 したがって、各リクエストは独立しており、それに応答するために必要なすべてのデータが含まれています。 不安定なネットワーク接続などの問題が原因で、各要求が失敗する可能性があります。 1つのタスクを処理するために複数の要求が必要になる場合、失敗のリスクが高まります。 したがって、ステートレスは信頼性を向上させます。

3番目に重要なことはキャッシュ可能性です。 クライアントアプリケーションは、頻繁に変更されないデータを保存できます。 その結果、サーバーに送信される要求の数を減らすことでパフォーマンスが向上します。 サーバーは、応答をキャッシュ可能またはキャッシュ不可としてマークする責任があります。 したがって、クライアントが不適切なデータをキャッシュするのを防ぎます。

次に、RESTfulAPIを階層化システムとして設計する必要があります。 関心の分離により、セキュリティとスケーラビリティが向上します。 クライアントアプリケーションは、サーバーに直接接続するのか、仲介者に接続するのかを知る必要はありません。 したがって、ロードバランサー、承認サーバー、共有キャッシュなどのミドルウェアを簡単に追加できます。

ついに、 RESTの重要な制約は、統一されたインターフェースです。 すべてのリソースは、単一の論理URIで表す必要があります。 さらに、関連するリソースを取得する方法に関する情報を提供する必要があります。 さらに、APIによって返されるデータの表現は、データベーススキーマに依存することはできません。

2.2. HTTPリクエスト

すでに述べたように、RESTfulAPIはほとんどの場合HTTPプロトコルを使用します。 それでは、RESTfulAPIへのHTTPリクエストの構造を分析してみましょう。 次の要素で構成されています。

  • requestメソッドは、リソースで実行される操作タイプを指定します。 最も基本的なものは、 POST、PUT、GET、DELETEです。
  • ヘッダーは、追加のメタデータのキーと値のペアです。 これらはオプションであるため、0個以上にすることができます。 HTTP仕様は、使用可能なヘッダーを定義します
  • リソースパスは、特定のリソースを記述するURIです
  • オプションの本文には、特定のリクエストを処理するために必要なデータが含まれています

それでは、そのようなリクエストの実際の例を見てみましょう。

POST https://jsonplaceholder.typicode.com/posts
Accept: application/json
Body:
{
    "title":"foo",
    "body":"bar",
    "userId":1
}

上記のリクエストは、新しいリソース、サンプルのブログ投稿を作成します。 POST HTTPメソッドを使用しており、次のURI https://jsonplaceholder.typicode.com/postsにリクエストを送信しています。

リクエストは単一のヘッダーAccept：application /jsonで構成されています。 クライアントが応答としてJSONデータ形式のみをサポートすることをサーバーに通知します。

最後に、作成したいブログ投稿データを含む本文があります。 JSONには、 title 、 body （ブログ投稿コンテンツ）、および userId （作成者の）の3つのフィールドが含まれています。

3. 石鹸

SOAP（Simple Object Access Protocol）は、分散環境のピア間でデータを転送するためにMicrosoftによって作成されたメッセージングプロトコルです。 狙う独立性、中立性、拡張性、および冗長性を提供します。 RESTとは対照的に、SOAPは標準化されています。 したがって、柔軟性がなく、与えられた制約に注意深く従う必要があります。 SOAPはいくつかの異なるプロトコルで動作できますが、ほとんどの場合、HTTPとペアになっています。 RESTとは対照的に、データ形式としてXMLを排他的にサポートします。

SOAPは重量級のプロトコルです。 シリアル化形式としてXMLを使用します。 XMLにはJSONよりもはるかに重いのは、主にボイラープレートコードがたくさん含まれているためです。 さらに、SOAPは WSDL （Webサービスドキュメント言語）を使用してAPIを記述します。 WSDLは、複雑で厚みのあるドキュメントXMLファイルです。 必須ではありませんが、通常は使用され、要求されます。

これらの欠点にもかかわらず、SOAPは安全で信頼できるプロトコルです。 大規模なエンタープライズアプリケーションは、標準化とセキュリティのために、SOAPを使用することがよくあります。

3.1. SOAPメッセージ

SOAPメッセージの構造を分析してみましょう。

SOAPメッセージは、次の要素で構成されています。

  • エンベロープ–XMLドキュメントをSOAPメッセージとして記述します
  • ヘッダー–タイムアウトなどの追加のメタデータを含むオプションのブロック
  • 本文–要求および応答データを伝送します
  • 障害–プロセス中に発生したエラーに関する情報を提供するオプションのブロック。 存在する場合、それは体内にあります

SOAPメッセージは、次の制約によって記述されます。

  • XMLドキュメントである必要があります
  • 封筒が含まれている必要があります
  • ヘッダーを持つことができます
  • 体が必要です
  • エンベロープ名前空間を使用する必要があります
  • DTD参照を持つ必要はありません
  • XML処理命令は必要ありません
  • エンコーディング名前空間を使用する必要があります

SOAPメッセージの例を見てみましょう。 以下の書類は自転車の価格を要求しています。

<soap:Envelope>
    <soap:Header>
        <maxTime value="10000"/>
    </soap:Header>
    <soap:Body>
        <GetPrice>
            <Name>bicycle</Name>
        </GetPrice>
    </soap:Body>
</soap:Envelope>

したがって、この例では、headerとbodyを含むSOAPエンベロープがあります。 ヘッダーにはmaxTimeタグが含まれています。このタグは、送信者が応答を待機する最大ミリ秒の値を示します。 次に、GetPriceブロックを含む本体があります。 到達したいAPIのメソッドを指定します。 GetPrice ブロックには、Name属性があります。 これは、bicycleの値を持つAPIのメソッドへのパラメーターパスです。

3.2. WSDL

先ほど申し上げました WSDLは、SOAPベースのWebサービスのドキュメントです。 さらに、SoapUIのようなツールがあります。 WSDLファイルに基づいてソースコードを生成します。 WSDLファイルは次の情報を提供します。

  • Webサービスによって提供されるサービス
  • 利用可能な操作を呼び出す方法
  • Webサービスの場所

の記事に従って、WSDLドキュメントの作成に関する詳細を確認してください。

4. RESTと 石鹸

SOAPまたはRESTを使用して作成されたWebサービスの基本についてはすでに知っています。 どちらも、Webサービスを作成するための確立された方法です。 少し違いますが。 Webサービスを作成する際に考慮すべき最も重要な機能を比較してみましょう。

初めに、 RESTは、転送データのデータ形式に関して弾力性があります。 RESTベースのAPIのさまざまなエンドポイントは、いくつかの形式を受け入れる場合もあります。 一方、SOAPはXML形式のメッセージのみを許可します。

SOAPは、WS-Security拡張機能により、追加のセキュリティ層を提供します。 このプロトコルは、組み込みのセキュリティメカニズムをWebサービスに適用します。 さらに、メッセージの整合性と機密性についても説明します。 同様のレベルのセキュリティを実装するRESTを使用すると、達成するのが難しく、時間がかかる場合があります。 RESTとSOAPの両方がSSLをサポートしていることは注目に値します。

パフォーマンスが主な問題である場合は、RESTの方が適しています。 軽量で、軽いデータ形式をサポートしています。 したがって、SOAPよりも必要な帯域幅は少なくなります。 さらに、RESTはキャッシュをサポートしているため、Webサービスのパフォーマンスをわずかに向上させることができます。

最後に、RESTはステートレスであることに注意することが重要です。 その結果、ステートレスAPIはスケーリングと拡張が容易になります。 ただし、サーバー側でユーザーのセッションを管理することが望ましい場合があります。 SOAPは、実装に応じて、ステートレスまたはステートフルのいずれかになります。

5. 結論

この記事では、RESTとSOAPを深く比較しました。 まず、RESTとそのコアコンセプトを紹介しました。 次に、RESTベースのWebサービスへのHTTPリクエストの簡単な例を分析しました。 SOAPの基本について説明しました。 続いて、SOAPメッセージの例を調査しました。 次に、WSDLファイルとその目的を簡単に定義しました。 最後に、SOAPとRESTの重要な機能を比較しました。