GNU/Linux >> Linux の 問題 >  >> Cent OS

SOAPとRESTAPI:直接比較

はじめに

ユースケースに適したAPIを決定するときは、SOAPとRESTを比較する可能性があります。これらの2つのソリューションは、今日のWeb開発で最も一般的に使用されているAPI(アプリケーションプログラミングインターフェイス)です。

SOAPとRESTの違い、直接比較できない理由、およびどちらを使用するかについては、以下をお読みください。

SOAPとRESTWebサービス:定義

SOAP API はXMLベースのメッセージングプロトコルであり、WebサービスがHTTPを介して構造化情報を通信および交換できるようにします。メッセージの書き込みにXMLを使用するため、プロトコルはプラットフォームや言語に依存せず、すべての操作で使用されます。

REST API は、REST API Webサービス(またはRESTful API)として広く知られているアプリケーションプログラミングインターフェイスです。インターフェイスは、HTTPプロトコルを介して必要なリソースの状態の表現を転送することにより、サービスとの対話を提供します。 APIはURL(または他のタイプのURI)に基づいており、通常はJSONデータ形式を使用します。

SOAP

SOAPはSimpleObjectAccessProtocolの略です。これは、RESTのかなり前にWebサービスへのアクセスを提供するために設計されました。このプロトコルは、データを交換し、アプリケーション間で通信を確立するための簡単な方法を導入しました(アプリケーションが異なるプラットフォームまたは異なる言語で構築されている場合でも)。

SOAPの主な機能のいくつかは次のとおりです。

  • XMLに基づいています。
  • プラットフォームに依存しません。
  • 組み込みのルールとコンプライアンスを課します。

SOAPメッセージは、アプリケーション層プロトコル(HTTPなど)を介してSOAPAPIに送信されるデータの要求を表します。各リクエストが処理された後、サーバーは必要なデータをXMLドキュメントで返します。

メッセージはXMLドキュメントとしてエンコードされ、次の要素で構成されます。

  • SOAPエンベロープ - <Envelope> ドキュメントをSOAPメッセージとして識別するルート要素です。これは子要素で構成されています-<Header> (オプション)および <Body> (必須)。
  • SOAPヘッダー - <Header> は、新しい機能を追加するためにヘッダー(アプリケーション関連)情報を渡すために使用されるエンベロープのオプションの子要素です。封筒には複数のヘッダーを含めることができます。
  • SOAP本体 - <Body> 受信者と交換する情報を含むエンベロープの必須の子要素です。
  • SOAP障害 - <Fault> は、処理中に問題が発生した場合にエラーとステータス情報を報告するために使用される、SOAP本体のオプションのサブ要素です。メッセージに含めることができる障害コンポーネントは1つだけです。

REST

SOAPとは異なり、RESTはプロトコルではなく、さまざまな方法で実装される一連の規制です。 RESTはRepresentationalStateTransferの略で、アプリケーションとサービスを構築するための一連のアーキテクチャー原則を指します。 RESTful Webサービスは、これらの原則に基づいて構築されたWebサービスです。

WebサービスをRESTfulと見なすには、特定の原則に従う必要があります。それらには以下が含まれます:

  • オンデマンドのコード。 サーバーは、必要に応じて実行可能コードをクライアントに送信できます。
  • 階層化されたシステム。 アーキテクチャは、さまざまな機能を備えたサーバーの複数のレイヤーで構成されています。
  • ステートレス。 すべてのクライアント/サーバー通信はステートレスです。リクエストは接続されておらず、クライアント情報はリクエスト間で保存されません。
  • キャッシュ。 やり取りを合理化するために、すべてのリソースをキャッシュ可能にする必要があります。
  • 均一なUI。 リソース、表現による操作、自己記述型メッセージ、およびアプリケーション状態のエンジンとしてのハイパーメディアを識別する統一されたインターフェースが必要です。
  • クライアントサーバーアーキテクチャ。 クライアントとサーバーは緩く結合されており、互いに独立しています。クライアントはユーザーインターフェースと状態に関心があり、サーバーはデータの保存、アクセス、管理、セキュリティを管理します。

リソースを取得するために、クライアントはサーバーにリクエストを送信します。クライアントが使用できるコマンドには、次の4つの基本的なタイプがあります。

  • 取得 -リソース表現を取得するため。
  • 投稿 -リソースを作成するため。
  • PUT -既存のリソースを編集するため。
  • 削除 -既存のリソースを削除するため。

SOAPとRESTWebサービス:簡単な比較

SOAPAPIとRESTAPIの基本を理解したところで、特定の基準によってそれらがどのように異なるかを直接比較してみましょう。

SOAP REST
デザイン 標準化されたプロトコル 建築様式
アプローチ 関数駆動型 データ駆動型
STATEFULNESS ステートフルまたはステートレス ステートレス
キャッシュ API呼び出しはキャッシュされません API呼び出しはキャッシュされます
リソース より多くの帯域幅、余分なオーバーヘッド 帯域幅が少なく、軽量
セキュリティ WS-security、SSL、built0in HTTPS、SSL
メッセージ フォーマット XML JSON、HTML、XML、YAML、プレーンテキストなど

プロトコルと建築様式

SOAPとRESTの主な違いは、それらの設計です。 SOAPは、事前定義されたルールを持つ標準化されたプロトコルです。

RESTは、推奨事項、制約、および緩いガイドラインを備えたアーキテクチャスタイルです。

サービスとしてのデータとリソースとしてのデータ

SOAPは機能駆動型です。 APIは操作を実行し、データはサービスとして利用できます。 RESTは通常、データ駆動型です。データは、APIを介してアクセスされるリソースとして利用できます。

ステートフルvs.ステートレス

デフォルトでは、SOAPはステートレスですが、コードを変更するだけでステートフルにすることができます。

RESTは完全にステートレスであり、サーバー側のセッションはありません。

キャッシュなしとキャッシュ

キャッシングは、ブラウザがサーバーに新しいリクエストを送信せずにデータを再利用できるようにする、時間とリソースの効率的な機能です。 SOAP API呼び出しをキャッシュにすることはできませんが、RESTAPI呼び出しはキャッシュ可能です。

リソースヘビーvs.ライトウェイト

SOAPとRESTに関しては、リソース要件に大きな違いがあります。エンベロープスタイルのペイロードトランスポートのため、SOAPは最初により多くのリソースを必要とします。さらに、データ量の多い要求を送信するには、より多くの帯域幅が必要です。

RESTは、必要なリソースと帯域幅が少ない軽量のソリューションです。

安全性の向上と安全性の低下

SOAPには、WS-Security、SSLサポート、および組み込みのACID準拠があります。したがって、機密情報を交換し、企業レベルのセキュリティを確保するのに適しています。

RESTはHTTPSとSSLをサポートし、一般に公開されているURLに使用されます。 TLSを使用した通信暗号化を提供しますが、サーバーレベルでの追加のセキュリティ実装なしに機密情報を処理するべきではありません。

単一のメッセージング形式とさまざまなメッセージング形式

SOAP APIは、XMLベースのメッセージングプロトコルのみをサポートします。 SOAPクライアントは、APIと通信するためにサードパーティのライブラリを必要とすることがよくあります。

REST APIはJSONを使用する傾向があり、HTML、XML、YAML、プレーンテキストなど、他のさまざまな形式をサポートします。RESTクライアントには、プログラミング言語に組み込まれたHTTPリクエストライブラリのみが必要です。

SOAPの長所と短所

利点

  • 言語、プラットフォーム、交通機関に依存しません。
  • 標準化され、安全で、企業に優しい。
  • 組み込みのエラー処理とWS標準を使用した事前構築された拡張性。
  • 特定の言語で使用する場合の自動化をサポートします。

短所

  • XMLドキュメントのサイズと帯域幅の要件が多いため、パフォーマンスが低下します。
  • クライアント/サーバー通信がWSDLコントラクトに依存する密結合アプリケーション。
  • RESTと比較してセットアップとテストがより複雑です。

RESTの長所と短所

利点

  • 理解と学習が簡単で、コーディングも簡単です。
  • 必要なリソースと帯域幅が少なくて済みます。
  • URIのおかげで、データにアクセスするためにルーティング情報は必要ありません。
  • キャッシュ機能によりパフォーマンスが向上します。
  • クライアントとサーバーが分離されているため、プロジェクトのさまざまなセクションにまたがる自律的な開発。

短所

  • 安全性が低く、機密データの操作には適していません。
  • ステートレスであるため、クライアントは必要に応じてステートを管理する必要があります。
  • 1回のリクエストで複数のデータを取得することはできません。

いつSOAPを選択しますか?

高度な制御と詳細な説明が必要な操作に対して、SOAPはフェイルプルーフの安定性を提供します。その事前定義された標準と制約により、RESTと比較してより優れたセキュリティが保証されます。さらに、SOAPはステートフル操作をサポートするWS構造を提供します。したがって、状態を維持することが重要な場合は、より適切な選択です。

いつRESTを選択しますか?

帯域幅とリソースが限られている場合は、RESToverSOAPを選択してください。また、ユースケースで情報の状態を維持することが優先されない場合は、ステートレスRESTAPIを選択してください。最後に、このソリューションは、キャッシングとコーディングの容易さが重要な役割を果たすシナリオに進む方法です。


Cent OS
  1. E2EネットワークAPIの使用方法は?

  2. CentOSへのWSO2APIManagerのインストール

  3. メディアサーバーの比較

  1. Tmux Socket Api?

  2. Pitchfork:サーバーを作成する

  3. Bash での日付比較

  1. PostgreSQLとMySQL:詳細な比較

  2. HadoopとSpark–詳細な比較

  3. 糸とNPM:包括的な比較