ログイン

REST vs SOAP - 最新のアプリケーションの構築

RESTとSOAPの主な相違点について説明します。いつどちらを使用するべきか、また、それらを保護するそれぞれの方法について説明いたします。

はじめましょう営業担当に相談する
rest-vs-soap

REST vs.SOAP

最新のアプリケーションを構築する際、開発者には多くの選択肢があります。静的言語か動的言語、確立されたJavaまたは比較的新しいGolang 、モノリシックなオールインワンフレームワークかモジュール化されたライブラリ、またはJavascriptでスタック全体を実行するかなど、これらは氷山の一角にすぎません。RESTまたはSOAPという問題は、開発者が選択しなければならない重要な決定事項です。

RESTとSOAP は、簡単に言えばアプリケーション間の通信方法です。最終目標は同じですが、RESTとSOAPを直接比較することはできません。RESTは、開発者がプロジェクトごとに異なる実装方法を選択する上での、一連のガイドラインであるのに対し、SOAPはデータ交換用に明確に、定義され標準化されたプロトコルだからです。それでも、どちらか一方を使用することの、利点と欠点に焦点を当てて比較することができます。どちらも業界全体で今でも広く使用されています。なぜ、いつ、どちらを使用するのかを明確に説明しましょう。

Representational State Transfer (REST)

Representational State Transfer (REST) は、Webサイト、モバイル アプリ、ゲームなど、最新のWeb ベースのアプリケーションの開発において、一般的に使用されているアーキテクチャパターンです。RESTベースのAPIを開発すると、HTTP経由でWebサービスの機能を公開したり、Web経由で対話することができます。GETや POST などのHTTP動詞を使用して、クライアントはAPIにリソースの取得または作成を指示します。

RESTful API は、Web上での相互運用性と柔軟性があり、非常に人気があります。このアーキテクチャで構築されたWebサービスは、それらを使用するアプリケーションとは独立して、進化することができます。RESTベースの APIには明確に定義されたセキュリティプロトコルはありませんが、JSON Web Token (JWT) がリクエストの認証および承認の、最も一般的な方法です。

メリット

  • ステートレス - Webサービスへの各呼び出しには、要求を処理するために必要なすべての情報が含まれており、クライアントサーバーコンテキストの保存に頼ってはいません。
  • 柔軟性 – RESTful API は、JSON、XML、Atom など、さまざまな形式のデータを受け入れて提供できます。JSON は、RESTベースのAPIで使用される最も一般的なデータ形式です。
  • キャッシュ可能 - 応答はキャッシュが可能であり、バックエンドへの不要な呼び出しを排除することで、 Webサービスのパフォーマンスを大幅に向上させることができます。

デメリット

  • 標準 – RESTベースのAPIを構築するための定義された標準はありません。ホワイトハウスRESTful API標準やREST APIチュートリアルなどの優れたリソースやガイドが多数ありますが、RESTベースの API には多くの順列があります。
  • HTTP – RESTfulアプリケーションはHTTPプロトコルに限定されています。

Representational State Transfer (REST)

Simple Object Access Protocol (SOAP)

一方、Simple Object Access Protocol (SOAP) は、データ交換用のプロトコルです。その強みは、クライアント/サーバーのやり取りを成功させるために従わなければならない、一連の規則と標準があることです。SOAP要求は、要求処理に必要な情報全てを含まなければならないエンベロープを介して配信されます。

通常、SOAP要求エンベロープは、オプションのヘッダーと必須の本文属性で構成されています。ヘッダーはセキュリティ資格情報やその他のメタデータなどの情報に使用され、ボディは実際のデータと発生したエラーを処理するために使用されます。これは、SOAPがデータ交換を処理する方法を簡略化したものです。詳細については、W3C仕様をご覧ください。SOAP Webサービスを書きたい場合は、わかりやすいチュートリアルをご覧ください。

メリット

  • WSDL – Webサービス記述言語 (WSDL) は、Webサービス メソッド、アクセス、およびその他のパラメーターを記述しており、これひとつで、APIの使用方法を学習することができます。
  • 拡張性 – WS-Security、WS-Addressing、WS-FederationなどのWSDL拡張機能により、アプリケーションの機能を大幅に強化できます。
  • 中立的なプロトコル – HTTP、SMTP、TCP、およびその他のアプリケーションレベルのプロトコルを介してアクセスできます。

デメリット

  • XML情報セット – SOAPはXMLを使用してペイロードデータを転送しますが、シリアル化に非常に長い時間がかかり、パフォーマンスの問題が発生する可能性があります。
  • 複雑な構文 – SOAPはXMLのみで動作し、データエンベロープの読み取りは困難で時間がかかる場合があります。

Simple Object Access Protocol (SOAP)

RESTのユースケース

RESTful APIはどこにでもあります。シングルページ アプリケーションからモノのインターネット (IoT) に至るまで、RESTベースのAPIを利用したサービスが普通になってきています。上部で説明した技術的な利点に加えて、RESTベースのAPIは、一般的に理解しやすく開発しやすいため、多くのビジネスに最適です。RESTはスタートアップ、モバイルアプリ、および最新のシングルページアプリケーション (SPA) を構築する開発者にとって最適な選択肢です。

多くの企業は単一の問題を解決し、どんなアプリケーションにもシームレスに統合するRESTful APIを提供することを中心に構築されています。Auth0はこの良い例です。そのほかのRESTの一般的なユースケースには、Twitterの RESTful API上に構築されたFalconアプリなど、企業が自社のデータセットを公開し、公開されたAPI上にサードパーティーが製品を構築するというケースがあります。

SOAPのユースケース

SOAP を使用するWebサービスは、エンタープライズ環境でよく見られます。銀行やヘルスケアなどの大規模なエンタープライズ環境では、SOAP を利用することで最もメリットが得られます。SOAP を使用すると、クライアント/サーバーのやり取りをより柔軟に制御できるからです。複雑なメソッドの表現をする場合、一般的にSOAPおよび ACID準拠のトランザクションを使用すると簡単になります。

SOAPは企業により適していますが、小規模な作業に使用できない、または使用すべきではない、というわけではありません。唯一の注意点は、SOAPアプリケーションの構築には一般的に時間がかかるということです。そのため、アイデアを試しているだけの場合は、複雑さに行き詰まる可能性があります。REST vs SOAPの議論における一般的な判断基準は、「SOAPを使ってWeb サービスを構築する理由が特になければ、RESTを使用する」ということです。

JWTを使用したREST API の認証

REST APIは一般的に Json Web Token (JWT) で認証されます。API エンドポイントを保護する必要がある場合は、戦略として、クライアントがAPI にリクエストを行う際、リクエスト者の ID を検証するトークンを含む認証ヘッダーを含めることを、クライアントに要求します。するとサーバーはトークンが有効であることを確認し、有効な場合はリクエストを処理します。

トークンベースの認証使用には多くの利点があり、こちらで詳しく学ぶことができます。REST APIはトークンベースの認証に限定されていません。Cookie/セッションベースの認証を使用することも、独自の認証メカニズムをロールすることもできます。

JWTによるRESTfulエンドポイントの保護

JWTを使用してRESTful APIを保護する方法の例を見てみましょう。毎日のモチベーションが上がる言葉を表示する、モバイルアプリケーションを作ったとします。毎日の言葉は、 /api/v1/quote にあるRESTful APIへのGETリクエストを介して取得されます。ユーザーからのフィードバックは素晴らしく、ユーザーは熱心に使用しています。ユーザーが、彼らの独自の言葉をアプリに送信できる機能を提供したい場合はどうなるでしょう。

本文に必要なデータを含む POST要求が /api/v1/quote に送信されると、送信された言葉がレビュー用にデータベースに保存されるように、新しいRESTfulエンドポイントが作成されます。ただし、誰もが言葉を送信できるというのは望ましくありません。登録ユーザーだけができるようにするべきです。APIの実装は次のとおりです。

...

routes.post('/api/v1/quote', function(req, res){
    // GETトークンは認証を探す援助機能です
    // 「 Bearer {token} 」の値を含むヘッダーをキー入力します
    // 次にBearerキーワードを取り除き、これらのみを返します。 {token}
    var token = getToken(req.headers.authorization);
    var quote = req.body.quote;

    jwt.verify(token, 'secret', function(err, decoded){
        if(err){
            res.json(err) // Return error details
        } else {
            // Save the quote to a database
            res.json({'message':'Quote Successfully Submitted. Thank you!'}); 
        }
    });
});

...

上記の実装では、ユーザーが /api/v1/quote エンドポイントに POST リクエストを送信すると、こちらでユーザーのJWTを抽出してトークンという変数に格納します。認証ヘッダーが存在しない場合は、ユーザーが認証されていないと想定できるため、それ以上の実行をこちらで停止します。トークンを取得した場合は、それが有効であることを検証します。トークンは、最初に署名されたシークレットに照らし合わせて検証されます。さらに、トークンの有効期限が切れていないかどうかを確認します。デコードされたオブジェクトには、トークンの作成時に追加できるユーザー権限などの追加データが含まれる場合がありますが、当社のデモではシンプルにしました。

有効なJWTを使用したAPIへのPOST

有効なJWTを使用したPOST

JWTを使用しないAPI への POST

JWTを使用しないPOST

すべてが完了しエラーが発生せずにユーザーが認証されたことが確認できると、言葉がデータベースに保存され、アプリを使用してくれたことへの感謝のメッセージが送信されます。この例では、エンドポイント実装内でトークン検証を行いました。実際の状況では、トークンの検証は、コールスタックの上位にあるミドルウェアを介して行うことが望ましいでしょう。

Auth0は、認証ワークフローの一部としてJWTの生成を簡単に処理することができます。ユーザーが正常にログインすると、Auth0はローカル ストレージまたはCookieに保存する JWT を返します。次に、リクエストがAPIに送信されるたびに、認証キーの下のヘッダーにトークンを追加します。サーバー側では、このトークンを検証する必要があります。これは、上記で見たように、多くのAuth0ソフトウェア開発キットの1つを使用する場合の簡単なタスクです。

SAMLを使用したSOAP APIの認証

Webサービスの保護と認証という点では、SOAPはRESTと同じくらい柔軟性があります。WS-Securityは、基本的なユーザー名/パスワード資格情報、SAML、OAuthなど、多くの認証モデルをサポートする重要な拡張機能です。

SOAP API の認証方法として一般的なのは、SAMLによるシングルサインオン (SSO) を使用することです。SAMLは、アプリケーション間での認証および承認資格情報の交換を促進することによって機能します。SAMLフェデレーション方式は、ユーザー、IDプロバイダー、およびサービスプロバイダーの３つの部分で構成されています。ユーザーはサービスプロバイダーから IDプロバイダーに要求を行い、要求が成功した場合、ユーザーは認証を受け、アプリケーションにアクセスできます。

SSOCircleを使用したSAMLシングルサインオン(SSO) の実装

SAMLシングルサインオン(SSO) の実装は困難で、時間のかかる作業になる場合があります。Auth0がお手伝いいたします！SSOCircleを使用してSAML SSOをどれだけ迅速にセットアップできるか見てみましょう。Auth0はサービスプロバイダー、SSOCircleは IDプロバイダーになります。つまり、ユーザーがログインを試みると、ID確認のためにユーザーはSSOCircleに移されます。

SSOCircleアカウントを作成したら、SSOCircleの公共のメタデータを取得しましょう。これはhttps://idp.ssocircle.com/ にアクセスすることで取得できます。ここから、 KeyDescriptor Signing X509 証明書 、 SingleSignOnServiceリダイレクト場所 、 SingleLogoutServiceリダイレクト場所 の３つの属性を取得します。

SSOCircle IDP

新しいファイルを作成し、X509証明書をコピーして、証明書を保存する新しいPEMファイルを作成することから始めます。以下に示すように、「BEGIN CERTIFICATE」と「END CERTIFICATE」を追加する必要があります。


-----BEGIN CERTIFICATE-----
MIIDATCCAemgAwIBAgICCpgwDQYJKoZIhvcNAQEFBQAwLjELMAkGA1UEBhMCREUx
EjAQBgNVBAoTCVNTT0NpcmNsZTELMAkGA1UEAxMCQ0EwHhcNMTEwNTE3MTkzNDEx
WhcNMjEwODE3MTkzNDExWjAuMQswCQYDVQQGEwJERTESMBAGA1UEChMJU1NPQ2ly
Y2xlMQswCQYDVQQDEwJDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB
ALm1xZq5goTh7NmdzZsZUJed9+7XauwuaNuGyZpIGRo4FsP1YPgs+40mYAoa9rDj
CEekixkfSI6nBUMdHuRIMHogyu/OVxskrL91SLO5m5u9JhgIhO/s9pnmnrnNUILf
RccE4+AEO1xsBQ/x1sY2zDZk+71Pfvifc9vVxedHpNAumbe1nb+CofUtAbF6PkHv
g3pqCoMPmC7m4NAr9h+zq3ekeWf8j5SOicupet9XhsO6zUr0Wga/Zs6J0khhYmFy
zpqoP2rLJ4a/9qduSGslOWsed6kD+zvhLMAUVcw3goli4VhepNzU5iGL9QdVj7m4
YQRMofBRYyL7tBWO6jzLpFcCAwEAAaMpMCcwFAYJYIZIAYb4QgEBAQH/BAQDAgD/
MA8GA1UdEwEB/wQFMAMBAf8wDQYJKoZIhvcNAQEFBQADggEBAKmOo8un97VFxNgo
iAzpU5fugKdAFFnKHTvUzDLQ81O455OyT6tcAsXHz6sy2c6GozqDV7xrXSqnues8
p9/w0KzVY9/YuxB90uiSJVh0zMxS+NwyfG1Od5Brloh9eBM4YulUI3V2ustcck17
2G4X4/QSK8uo0bjELUzSNAGj7uypsKKXjX++enfAJzLSsqk3Y8Tmon4R6GYBj4mo
1nL6ujeXqB/kH44XnEmU7ojyIC1kawFRdY4GDFIq3HOBFNzlNbJVL+jKdgTQJTET
rNTDjxXmxwpZ90+lPbEaLQeElwAQi7pMtcqD/f8Dqaifk9ZvpCB7NC+oLM5ej9nK
TawsVqs=
-----END CERTIFICATE-----

このファイルを SSOCircle.pem として保存します。Auth0のダッシュボードに移動し、[接続] に移動してから [エンタープライズ] サブメニューに移動し、SAMLP IDプロバイダー セクションの + アイコンをクリックして、新しいSAMLP IDプロバイダー接続を作成します。ここで構成できる設定はたくさんありますが、このデモでは最初に接続名を設定します。これは任意の名前を付けられます。このデモでは電子メールのドメインは省略しますが、電子メールドメインセクションで、どれがシングルサインオンで自動的に動作するドメインなのかを定義します。通常、これが御社の企業ドメインになります。

パブリックSSOCircleメタデータから受け取ったサインインと、サインアウトのURL をそこに挿入します。構成の最後の部分で、前に作成した .pem 証明書をアップロードします。これらの設定を構成したら、残りは無視して [保存] をクリックします。

設定を保存すると、続行するように求められ、接続のメタデータを取得する必要があります。次のようになります。

<EntityDescriptor entityID='urn:auth0:{ACCOUNT_NAME}:{CONNECTION_NAME}' xmlns='urn:oasis:names:tc:SAML:2.0:metadata'>
  <SPSSODescriptor WantAssertionsSigned='true' protocolSupportEnumeration='urn:oasis:names:tc:SAML:2.0:protocol'>

    <SingleLogoutService Binding='urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect' Location='https://{ACCOUNT_NAME}.auth0.com/samlp/logout'/>
    <SingleLogoutService Binding='urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST' Location='https://{ACCOUNT_NAME}.auth0.com/samlp/logout'/>
    <NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress</NameIDFormat>
    <NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameid-format:persistent</NameIDFormat>
    <NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameid-format:transient</NameIDFormat>
    <AssertionConsumerService Binding='urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST' Location='https://{ACCOUNT_NAME}.auth0.com/login/callback?connection={CONNECTION_NAME}' index='0' isDefault='true'/>
  </SPSSODescriptor>
</EntityDescriptor>

これは接続メタデータであり、SSOCircles 側で新しいサービスプロバイダーを登録するためにこれを使用します。SSOCircleに移動し、[メタデータの管理] セクションに移動します。そこで、[新しいサービスプロバイダーの追加] をクリックします。［FQDN (完全修飾ドメイン名) ］、この場合は［auth0.com］ を入力し、アサーションセクションで送信される属性内で［メールアドレス］を選択し、最後に、［XML メタデータ］を提供されたテキスト領域に貼り付けてください。[送信] をクリックすると、Auth0サービス プロバイダーが登録されます。

接続が成功したことをテストするには、[SAMLP ID プロバイダー] セクションの下にある [管理] ボタンをクリックし、[試行] (再生アイコン) をクリックします。すべてがうまくいけば、以下のような画面が表示されるはずです。以上です！これで、Auth0がサービスプロバイダー、そしてSSOCircle が IDプロバイダーとして機能する、 SAMLシングルサインオンが統合されました。SAMLフェデレーションの実装に関する詳細なガイドについては、こちらをご覧ください。

SSOCircleの接続成功

Auth0でRESTまたはSOAP認証を簡単に

RESTfulサービスを使用するモバイル アプリを構築する場合でも、エンタープライズのSOAPアプリを構築する場合でも、認証に関してはAuth0にお任せください。

JWT認証は Auth0の得意分野です。広範な認証ライブラリと、多くのプログラミング言語およびフレームワーク用のSDKを使用すると、認証を数分で実行できます。Facebook、Twitter、Google など30を超えるソーシャルコネクションのサポートと、既存のユーザーデータベースを使用する機能により、Auth0への切り替えは簡単にできます。

Auth0は、SAMLベースのフェデレーションで、サービスプロバイダーとIDプロバイダーの両方として機能します。SalesforceやBoxなどのアプリケーションは、Auth0をIDプロバイダーとして使用し、ユーザーがAuth0を介してそのようなサービスにログインできるようにしています。Auth0をサービス プロバイダーとして機能させる場合、Auth0は認証要求を SSOCircle、OneLogin、またはその他のSAML準拠のIDプロバイダーなどのIDプロバイダーに送信します。

登録無料

今すぐ構築を開始し、Auth0 ID プラットフォームでお使いのアプリを保護しましょう。

無料でお試しください営業へのお問い合わせ
3D login box