レベル: 中級 Robert Peterson, WebSphere Enablement, Austin, TX, IBM
2009年 3月 04日 IBM® WebSphere® DataPower® SOA アプライアンスを利用するWeb 2.0とRESTを紹介するこの記事の中で、WebSphere DataPowerの上で厳密なRESTサービスを構築し、それをバックエンドのWebサービスと連携させる方法を学習します。ここに含まれるRESTのサンプル・コードはベスト・プラクティスを示すもので、実装方法と構成方法の詳しい手順も紹介します。
はじめに
REST (Representational State Transfer) は重要な Web 2.0技術であり、SOAPベースのWebサービスやEnterprise JavaBeans™ (EJB)といったサービスを提供する他の技術と比べても人気の高い選択肢になっています。多くの著名な団体が、サービスとしてRESTのAPIを提供しています。よくある事例として、既存のレガシー・システムの前面にRESTのインターフェースを公開するケースがあります。この記事では厳密なRESTに目を向け、IBM WebSphere DataPower XS40 や XI50のSOAアプライアンスを利用して、既存のWebサービスの前面にRESTのインターフェースを公開するための方法を、例を示しながら紹介します。
Web 2.0 は新しい技術の普及にたいへん役立っています。その中には、まったく新しい技術もあれば、古い技術をWeb 2.0に適用して、再活性化されたものもあります。こうした新しいプロトコルや技術を、既存のエンタープライズ・システムと連携させる必要性が高まっています。WebSphere DataPowerは図1に示すように、Web 2.0とSOAを連携させる、独特な位置付けのものです。WebSphere DataPowerはATOMフィード・メッセージやREST 呼び出しなどの Web 2.0のリクエストの利用を可能にし、Webサービス、JMS、メインフレーム接続(例:IMS接続)などのエンタープライズ・プロトコルと連携を可能にします。この記事で扱うのは、RESTクライアントのリクエストを標準のWebサービスのバックエンド・システムへと橋渡しする事例です。
図1. Web 2.0とSOAの空間におけるWebSphere DataPower
前提
この記事で紹介する手順に従って作業を進める場合は、以下の環境が必要になります。
- IBM WebSphere Application Server V6.1 以上: この記事の例で利用されるバックエンドのWebサービス・プロバイダーは、WebSphere Application Server V6.1です。必要に応じて、デモ用のWebサービス・アプリケーションをWSDLから実装するのに、他のアプリケーション・サーバーを使うことも可能です。WebSphere Application Serverの試用版をダウンロードすることもできます。
- IBM WebSphere DataPower XI50またはXS40 Firmware V3.7 以上: WebSphere DataPowerはRESTリクエストをWebサービスに変換してルーティングするために利用されます。
- Curl: HTTP上でファイルを送信するためのオープン・ソースのコマンドライン・ユーティリティーです。この記事では、RESTのHTTPメソッドをテストするためにCurlを利用しています。Curlをダウンロードしてください。
RESTの定義
この記事の中では、RESTは単にXMLやHTTPではありません。RESTパターンから恩恵を受け、RESTパターンに忠実であるためには、従うべきルールがあります。以下に、この記事の中で使われるREST用語と説明を示します。
- 緩いREST(Loose REST)は、HTTP上のドメイン・データで、追加の層(SOAPなど)を持たず、cookieも持たないものです。これはXML/HTTPと同義語で、本質的には貧者のSOAPです。緩いRESTは、唯一のHTTPメソッド(POST)を利用し、RPC型のコミュニケーションに従います。
- 厳密なREST(Strict REST)は、リソース・ベースのコミュニケーション・パターンを提供します。ネットワーク上で特定可能なリソースは、「動詞」の共通セットで利用されます。
- 名詞(Nouns)は、アクセスを単純化します。すべてのリソースや名詞はグローバルURLにより、ネットワーク上で特定可能です。リソースは、他の関連するリソースに対して”href”参照を持ちます。リソースを特定する唯一の方法はURLです。
- 動詞(Verbs)は行為を単純化します。動詞の共通セットは、全てのリソースへのアクセスに利用されます。HTTPメソッドのGET、PUT、POST、DELETEは、取り出し、更新、作成、削除(CRUD)関数です。利用される動詞はこれがすべてです。
- 表記(Representations)はフォーマットを単純化します。RESTは各リソースの複数の別の表記を提供します。リソースは、XML、JSON、HTML、テキスト、イメージなどにより表記されます.リソースから表記をインスタンス化したり、その逆の処理をすることは、サーバー上で行われます。クライアントは、URIのパラメータや”Accept”ヘッダーにより、好みの表記を選ぶことができます。
図2. RESTトライアングル
最終的な目標は、リソースに一様なインターフェースを持たせることです。つまり、すべてのリソースが特定可能で、リソースに対する共通の動詞セットがあり、柔軟かつ理解されるリソースの表記があることが目標です。これにより徹底的な単純化が可能となり、その結果、データが任意のアプリケーションから容易にアクセスできるようになります。
厳密なRESTの主要なメリットは、ハイパーメディア・リンクです。リソースのコレクション(リソースを集めたもの)を入手すれば、その要約とリンク(そこに含まれる各リソースへのURI)を返すことが可能です。リソースのコレクション自体が、またひとつのリソースとなります。クライアントは、各リソースへのよく知られたURIを利用する代わりに、こうしたリンクを持つリソースのコレクションへのURIを動的に発見することができます。このため、サーバーは、クライアントに影響を与えることなしに、URIをコレクションのリソースへと変更することができるのです。
別の主要なメリットは、自己記述型のメッセージです。HTTPメソッドとcontent-typeは記述的なものです。それらはアクションとリソース表記を記述します。こうしたものを無視するSOAPとは異なるのです。このため、仲介者がメッセージ・コンテンツをパースせずに、メッセージを扱うことができるようになります。
厳密なRESTのHTTPメソッドで利用される動詞は以下の通りです。
- GET: サーバーからリソースを取得します。このメソッドはIdempotent (1回目の実行でも2回目以降の実行でも処理が同じ)であり、安全です。
- DELETE: サーバーからリソースを削除します。このメソッドはIdempotentであり、安全ではありません。
- PUT: 特定のURLにリソースを作成します。もし、このURLに既にリソースが存在していたら、上書きされます。このメソッドはIdempotentであり、安全ではありません。
- POST: リソースを特定の集めたものの中に作成します。サーバーはリソースのURLを選ぶことができ、また、「これを処理してください」というタイプのコミュニケーションに利用します。このメソッドはIdempotentではなく、安全でもありません。
厳密なRESTは、以下のようなものです。
- デザイン・パターン、またはアーキテクチャー・スタイルである
- オブジェクト(リソース)に基づき、メソッド(サービス)に基づかない。
- セッションレスで、ステートレスである。
- キャッシュ可能である。
- GETメソッドは安全でIdempotentである。
- PUTメソッドはキャッシュ・コンテントを無効化する。
厳密なRESTは、以下のようなものではありません。
- SOAPメッセージからSOAPエンベロープを取り除く。
- HTTP Bodyの代わりに照会文を利用する。
- すべての操作にHTTP GETを利用する。
- すべての操作にHTTP POSTを利用する。
- RPCである。
- サービス・インターフェースに対して1:1のFaçadeとなる。
- 技術である。
WebSphere DataPowerによるRESTの公開
図3は厳密なRESTインターフェースを公開するWebSphere DataPowerの概要を示します。ここでは、バックエンドにあるSOAPベースのWebサービスがRESTインターフェースを提供しています。XMLファイヤー・ウォールがクライアントからのGET/PUT/POST/DELETEリクエストを受付け、そこで対応するSOAPリクエストに変換し、WS-Proxyに送ります。WS-Proxyはオプションです。SOAPリクエストは直接バックエンドに送っても構いません。しかし、将来的に監視やセキュリティーが必要になるかもしれないことから、これはまったく推奨できません。
したがって、WS-ProxyをREST変換の構成の一部とすることがベスト・プラクティスです。
図3. 厳密なRESTインターフェースを公開するWebSphere DataPowerの概要
XMLファイヤー・ウォールがLoopbackとして構成されている点にも注目してください。これが必要なのは、バックエンド(この場合はWS-Proxy)がPOSTメソッドのリクエストだけを受け付けるからです。HTTPメソッドは読み取り専用のシステム・コールとして利用可能です。例えば、クライアントがHTTP DELETEメソッドを送ると、DELETEメソッドはPOSTメソッドに変換できません。このように、XMLファイヤー・ウォールのバックエンド設定は利用されず、XSLの明示的なURL指定アクセスまたはSOAPコールがHTTP POSTメソッドを利用して、WS-Proxyとのコミュニケーションをとります。
DemoService の例
ここからは、共通の例を使ってWebSphere DataPowerがバックエンドのWebサービスをRESTインターフェースとして公開する方法を示していきます。WebサービスのサンプルであるDemoServiceは、シンプルなプロジェクト管理ツールで、簡単なプロジェクトを作成、編集、照会することができます。DemoServiceで利用可能な操作を表1に示します。
表1. DemoService 操作
| 操作 | 説明 |
|---|
| createProject | サーバー上にプロジェクト名、記述、IDから構成されるプロジェクトを作成します。プロジェクトIDが生成され、レスポンスとして返されます。 |
|---|
| updateProject | プロジェクトに変更を加えます。プロジェクトID、プロジェクト名、記述が必要です。 |
|---|
| getProject | プロジェクトから名前と記述を取得します。プロジェクトIDはりクエストの中で提供される必要があります。 |
|---|
| listProjects | すべてのプロジェクトを返します。 |
|---|
| deleteProject | サーバーからプロジェクトを削除します。プロジェクトIDがリクエストの中で提供される必要があります。 |
|---|
次のセクションでは、これらの操作がどの様にRESTインターフェースにマップされるのか示します。RESTインターフェースは、すべてのHTTPメソッド、GET、POST、PUT、DELETEから構成されています。
DemoServiceのインストール
この記事に含まれるDemoServiceのアプリケーション・ファイルをダウンロードし、以下の手順に従って、DemoService.earをWebSphere Application Server V6.1上にインストールしましょう。
- 管理コンソールから、[アプリケーション=>新規アプリケーションのインストール]を選択します。
- [参照...]を選択して、図4のようにDemoService EARを選びます。
- [次へ]を選択します。
図4. DemoService アプリケーションのインストール
- 左側のメニューで、[ステップ3]をクリックして、[終了]を選択します。
- インストール終了後、[保管]をクリックします。
WS-Proxyのセットアップ
以下のステップに従って、WS-Proxyを作成しましょう。
- WebSphere DataPowerのコントロール・パネルから、[Web Service Proxy => Add]を選択します。
- 名前に「
demo-service-proxy」 と入力して、[Create Web Service Proxy]を選択します。
- demoService.wsdlファイル(ダウンロードしたファイルに含まれます)をアップロードして、[WS-Policy References]は[off]を選択して、[Next]をクリックします。 (図5).
図5. WS-Proxyの構成
- [Local Endpoint Handler and HTTP Front Side Handler]の下の[+]を選択します。
- 名前に「
http-9080」 、ポート番号に「9080 」を入力して、[Apply]をクリックします。
- WS-Proxy configuration panelに戻り、[Edit]と[Remove]の下の[Add]を選択し、下の[Next]をクリックします。
これでWS-Proxyのセットアップは完了です。続行する前に、ここまでの構成を保管しましょう。
WebSphere DataPower構成例のインポート
WebSphere DataPowerの構成例をXS40やXI50アプライアンスにインポートするには、 以下のように行います。
- DataPower管理コンソールで、[Administration =>
Configuration => Import Configuration]を選択します。
- [Browse...] をクリックして、REST-DP-Export.zip (ダウンロードしたファイルに含まれます)を選択して、[Next]を選択します。 (図6)
図6. DataPowerドメインのインポート
- [Import]を選択します。
REST XMLファイヤー・ウォール
XMLファイヤー・ウォールの処理ポリシーを見てみると、いちばん初めに実行されるスタイル・シートは "save-http-method.xsl"という名前のものであることが分かります。これは受信するメッセージのタイプには依存しません。このスタイル・シートの目的は、HTTPメソッドを提供するシステム変数を読み込み、それを後で利用するために保管しておくことです。
HTTPメソッドごとに処理ルールをセットアップするのが、ベストプラクティスです。HTTPメソッドは、dp:http-request-method()システム・コールによりアクセスすることが可能です。リスト1のスタイル・シートは、HTTPメソッドをキャプチャーし、var://context/projects/http-methodというコンテキスト変数に保管します。
リスト1. save-http-method.xsl
<xsl:stylesheet
xmlns:dp="http://www.datapower.com/extensions"
xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
extension-element-prefixes="dp"
exclude-result-prefixes="dp"
version="1.1">
<xsl:template match="/">
<xsl:message><xsl:value-of select="dp:http-request-method()"/></xsl:message>
<dp:set-variable name="'var://context/projects/http-method'"
value="dp:http-request-method()" />
</xsl:template>
</xsl:stylesheet> |
いったんHTTPメソッドがコンテキスト変数に保管されると、そのHTTPメソッドにマッチする処理ルールを選ぶために、コールアクションを利用します。処理ルールの名前は、var://context/projects/http-methodの可能な文字列変数(GET, PUT, POST, DELETE)に対応するものです。図7 は、コールアクションと、HTTPメソッドに対応する4つの処理ルールです。各処理ルールはコールアクションにより呼び出されます。
図7. コール処理アクション
以降のセクションでは、各処理ルールと、Curlを利用してRESTをテストする方法を紹介していきます。
REST動詞の利用
以降のセクションでは、図7のようなREST XMLファイヤー・ウォール・ポリシーの実装を記述しています。これはWebSphere DataPowerのREST開発の練習問題としても使うことができ、他のRESTプロジェクトの出発点となる実用的な構成としても使うことができます。また、単に、WebSphere DataPowerでのRESTからSOAPへの変換がどの様なものであるかを見る基準にもなります。以降のセクションは、WebSphere DataPowerの各処理ルール(POST、PUT、GET、DELETE)によって提供されます。同様のフォーマットが、各処理ルール用の実装を記述するのにも使われます。ここで使われる用語は以下の通りです。
- リクエスト・ペイロード: RESTリクエスト・ペイロードの例
- レスポンス・ペイロード: RESTレスポンス・ペイロードの例
- アクション: 処理アクションで処理ルールを表すイメージを含む。番号は処理アクションのシーケンス番号です。
- コード・リスト: 処理ルールの中で定義されるスタイル・シート用のコード・リストです。各リストは、対応するアクション図の中のシーケンス番号に従って番号が付けられています。
- Curlコマンド: 対応するHTTPメソッドでRESTサービスをよびだすCurlコマンドの例です。
POST
POST処理ルールは、SOAP APIのcreateProject操作に対応します。
- リクエスト・ペイロード: project
リスト2. POSTリクエスト・ペイロード
<q0:project xmlns:q0="http://soap.example.com/demoService/REST" >
<q0:description>Research of ancient cultures</q0:description>
<q0:owner>Alice</q0:owner>
</q0:project> |
- レスポンス・ペイロード: なし。ただし、”location” HTTPヘッダーが新規作成されたリソースのURLを与えるべきである。
- アクション:
図8. POST処理ルール
(1) rest-post-to-soap.xsl 変換: このスタイル・シートはRESTプロジェクト・ペイロードをSOAPペイロードに変換します。プロジェクト記述と所有者はRESTリクエストからコピーしています。また、createProject SOAPアクションは、var://context/rest/soap-action というコンテキスト変数に保管します。
リスト 3. rest-post-to-soap.xsl
<xsl:stylesheet
xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:dp="http://www.datapower.com/extensions"
xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
extension-element-prefixes="dp"
exclude-result-prefixes="dp"
version="1.1">
<xsl:template match="/">
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:dem="http://soap.example.com/demoService/">
<soapenv:Header/>
<soapenv:Body>
<dem:createProjectRequest>
<dem:newProject>
<dem:description>
<xsl:value-of select="//*[local-name()='description']"/>
</dem:description>
<dem:owner>
<xsl:value-of select="//*[local-name()='owner']"/>
</dem:owner>
</dem:newProject>
</dem:createProjectRequest>
</soapenv:Body>
</soapenv:Envelope>
<dp:set-variable name="'var://context/rest/soap-action'"
value="'http://soap.example.com/demoService/createProject'"/>
</xsl:template>
</xsl:stylesheet> |
(2) call-demo-service.xsl変換: このスタイル・シートは、SOAPアクションを持つSOAPペイロードをdemoService Webサービス proxyに送信します。それがどのように以前保管されていたvar://context/rest/soap-action変数を利用するかに注意してください。 このスタイル・シートは後続の処理ルールの中でも使われます。
リスト4. call-demo-service.xsl
<xsl:stylesheet
xmlns:dp="http://www.datapower.com/extensions"
xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
extension-element-prefixes="dp"
exclude-result-prefixes="dp"
version="1.1">
<xsl:template match="/">
<xsl:copy-of select="dp:soap-call('http://127.0.0.1:9080/DemoService
/services/localDemoServiceSOAP',/,'',0,dp:variable('var://context
/rest/soap-action'))"/>
</xsl:template>
</xsl:stylesheet> |
(3) set-location-header.xsl 変換: このスタイル・シートは、SOAPレスポンスからIDを抽出し、新規に作成されたリソース用のURLと共にlocation HTTPヘッダーに設定します。
リスト5. set-location-header.xsl
<xsl:stylesheet
xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:dp="http://www.datapower.com/extensions"
xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
extension-element-prefixes="dp"
exclude-result-prefixes="dp"
version="1.1">
<xsl:template match="/">
<xsl:variable name="id" select="//*[local-name()='id']/text()" />
<dp:set-http-response-header name="'Location'"
value="concat('/projects/',$id)" />
</xsl:template>
</xsl:stylesheet> |
POSTのRESTメソッドをテストするには、リクエストメッセージが必要ですが、これはリスト2に含まれています。ペイロードはRESTPostRequest.xmlとして保管されています。
リクエストをWebSphere DataPowerに送信するには、以下のCurlコマンドを使用してください。
curl --data-binary @RESTPostRequest.xml http://DPHOST:8501/projects/2 -v
-v フラグでWebSphere DataPowerから返されるヘッダーが見えるようになります。レスポンス・ペイロードはありませんが、locationヘッダーに特に注目してください。loationヘッダーは新規に作成されたプロジェクトのURLを返しています。
例えば、3番目のプロジェクトが作成されたとき、”/projects/3”を返します。
PUT
PUT処理ルールは、SOAP APIのupdateProject操作に対応します。
- リクエスト・ペイロード: project
リスト6. PUT request payload
<q0:project xmlns:q0="http://soap.example.com/demoService/REST" >
<q0:id>2</q0:id>
<q0:description>Astronomy Project</q0:description>
<q0:owner>Athena</q0:owner>
</q0:project> |
- レスポンス・ペイロード: なし。
- アクション:
図9. Put処理ルール
(4) rest-put-to-soap.xsl 変換: Tこのスタイル・シートはRESTプロジェクトのペイロードをSOAPペイロードに変換します。プロジェクトID、プロジェクト記述、所有者がRESTリクエストからコピーされます。また、updateProject SOAPアクションがrest/soap-actionというコンテキスト変数に保管されます。
リスト7. rest-put-to-soap.xsl
<xsl:stylesheet
xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:dp="http://www.datapower.com/extensions"
xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
extension-element-prefixes="dp"
exclude-result-prefixes="dp"
version="1.1">
<xsl:template match="/">
<soapenv:Envelope
xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:dem="http://soap.example.com/demoService/">
<soapenv:Header/>
<soapenv:Body>
<dem:updateProjectRequest>
<dem:project>
<dem:id>
<xsl:value-of select="//*[local-name()='id']"/>
</dem:id>
<dem:description>
<xsl:value-of select="//*[local-name()='description']"/>
</dem:description>
<dem:owner>
<xsl:value-of select="//*[local-name()='owner']"/>
</dem:owner>
</dem:project>
</dem:updateProjectRequest>
</soapenv:Body>
</soapenv:Envelope>
<dp:set-variable name="'var://context/rest/soap-action'"
value="'http://soap.example.com/demoService/updateProject'"/>
</xsl:template>
</xsl:stylesheet> |
(5) call-demo-service.xsl変換: これはリスト4で使われたのと同じスタイル・シートです。このスタイル・シートはSOAPアクションを持つSOAPペイロードをdemoService Webサービスproxyに送信します。それがどの様に以前に保管されたrest/soap-action変数を利用するか注意してください。
PUTのRESTメソッドをテストするには、リクエストメッセージが必要ですが、これはリスト 6に含まれています。ペイロードはRESTPutRequest.xmlとして保管されています。
リクエストをWebSphere DataPowerに送信するには、このCurlコマンドを使用してください。
curl -T RESTPutRequest.xml http://DPHOST:8501/projects/2
空白のレスポンスは正常であり、期待通りです。
GET
GET処理ルールは、SOAP APIの getProject とlistProject操作に対応します。それぞれ、単一のプロジェクトを取り出すことと、プロジェクトのリスト(コレクション)を取り出すことができます。
- リクエスト・ペイロード: なし
- レスポンス・ペイロード: Project, ListProject
リスト8. GET Projectレスポンス・ペイロード
<q0:project xmlns:q0="http://soap.example.com/demoService/REST" >
<q0:id>2</q0:id>
<q0:description>Astronomy Project</q0:description>
<q0:owner>Athena</q0:owner>
</q0:project> |
リスト9. GET ListProjectレスポンス・ペイロード
<?xml version="1.0" encoding="UTF-8"?>
<q0:projectList xmlns:q0="http://soap.example.com/demoService/REST">
<q0:project>
<q0:id>3</q0:id>
<q0:description>Research of ancient cultures</q0:description>
<q0:owner>Athena</q0:owner>
</q0:project>
<q0:project>
<q0:id>1</q0:id>
<q0:description>Astronomy project</q0:description>
<q0:owner>Alice</q0:owner>
</q0:project>
<q0:project>
<q0:id>0</q0:id>
<q0:description>Summer landscape project</q0:description>
<q0:owner>Amber</q0:owner>
</q0:project>
</q0:projectList> |
- GETメソッドの追加の手順は、非XMLに対する処理ルールをセットすることです。GET処理ルールはリクエスト・ペイロードを持たないので、XMLの検査と検証をオフにする必要があります。
そのため、OBJECTSメニューを開いて、[XML Processing => Processing Rule => GET]を選択してください。[Non-XML Processing]で[on]を設定してください。 (図10)
図10. XMLプロセスの無効化
- アクション:
図11. GET処理ルール
(6) rest-get-to-soap.xsl 変換: このスタイル・シートはプロジェクトかプロジェクトのリストを取得するためのSOAPリクエストを組み立てます。
URLとSOAPペイロードのlistProjectRequestかgetProjectRequestからIDが抽出されます。また、SOAPアクションが、rest/soap-actionというコンテキスト変数に、listProjectまたはgetProjectとして保管されます。
図10. rest-get-to-soap.xsl
<xsl:stylesheet
xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:dp="http://www.datapower.com/extensions"
xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
extension-element-prefixes="dp"
exclude-result-prefixes="dp"
version="1.1">
<xsl:template match="/">
<xsl:variable name="url" select="dp:variable('var://service/URI')"/>
<xsl:choose>
<xsl:when test="$url = '/projects'">
<soapenv:Envelope
xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:dem="http://soap.example.com/demoService/">
<soapenv:Header/>
<soapenv:Body>
<dem:listProjectsRequest></dem:listProjectsRequest>
</soapenv:Body>
</soapenv:Envelope>
<dp:set-variable name="'var://context/rest/soap-action'"
value="'http://soap.example.com/demoService/listProjects'"/>
</xsl:when>
<xsl:otherwise>
<xsl:variable name="id" select="substring-after($url,'/projects/')"/>
<soapenv:Envelope
xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:dem="http://soap.example.com/demoService/">
<soapenv:Header/>
<soapenv:Body>
<dem:getProjectRequest>
<dem:id><xsl:value-of select="$id"/></dem:id>
</dem:getProjectRequest>
</soapenv:Body>
</soapenv:Envelope>
<dp:set-variable name="'var://context/rest/soap-action'"
value="'http://soap.example.com/demoService/getProject'"/>
</xsl:otherwise>
</xsl:choose>
</xsl:template>
</xsl:stylesheet> |
(7) call-demo-service.xsl: 既に説明済みですが、call-demo-serviceスタイル・シートがここでも利用されます。
(8) rest-transform-get-response.xsl: いったんSOAPレスポンスがバックエンドから取り出されると、RESTペイロードに変換される必要があります。プロジェクトID、記述、所有者がどの様に入力SOAPメッセージから取り出されるかに注意してください。また、それを用いて、RESTレスポンスがどの様に組み立てられるかにも注意してください。この処理はプロジェクト・リストが返される場合には繰り返されます。
図11. rest-transform-get-response.xsl
<xsl:stylesheet
xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:dp="http://www.datapower.com/extensions"
xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
extension-element-prefixes="dp"
exclude-result-prefixes="dp"
version="1.1">
<xsl:template match="/">
<xsl:variable name="url" select="dp:variable('var://service/URI')"/>
<xsl:choose>
<xsl:when test="$url = '/projects'">
<q0:projectList xmlns:q0="http://soap.example.com/demoService/REST">
<xsl:for-each select="//*[local-name()='project']">
<q0:project>
<q0:id>
<xsl:value-of select="*[local-name()='id']"/>
</q0:id>
<q0:description>
<xsl:value-of select="*[local-name()='description']"/>
</q0:description>
<q0:owner>
<xsl:value-of select="*[local-name()='owner']"/>
</q0:owner>
</q0:project>
</xsl:for-each>
</q0:projectList>
</xsl:when>
<xsl:otherwise>
<q0:project xmlns:q0="http://soap.example.com/demoService/REST">
<q0:id>
<xsl:value-of select="//*[local-name()='id']"/>
</q0:id>
<q0:description>
<xsl:value-of select="//*[local-name()='description']"/>
</q0:description>
<q0:owner>
<xsl:value-of select="//*[local-name()='owner']"/>
</q0:owner>
</q0:project>
</xsl:otherwise>
</xsl:choose>
</xsl:template>
</xsl:stylesheet> |
GETリクエストをWebSphere DataPowerに送信するには、このCurlコマンドを使用してください。(プロジェクトIDは2です。):
curl -G http://DPHOST:8501/projects/2
GETリクエストをすべてのプロジェクトのリストに送信するには、このCurlコマンドを使ってください。プロジェクトIDが省略されていることに注意してください。
curl -G http://DPHOST:8501/projects
DELETE
DELETE処理ルールは、SOAP APIのremoveProject操作に対応します。
- リクエスト・ペイロード: なし
- レスポンス・ペイロード: なし
- 前と同様に、DELETE処理ルールは、非XML処理にセットされなければいけません。これは空白の入力を受け付けるからです。前に示されたGET処理ルールの手順に従ってください。
- アクション:
図12. DELETE処理ルール
(9) rest-delete-to-soap.xsl 変換: このスタイル・シートはプロジェクトを削除するためのSOAPペイロードを組み立てます。これはdeleteProject SOAP操作に対応します。プロジェクトIDがURLから抽出され、SOAPペイロードを組み立てるのに利用されています。また、deleteProject SOAPアクションがrest/soap-actionというコンテキスト変数に保管されるます。
リスト12. rest-delete-to-soap.xsl
<xsl:stylesheet
xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:dp="http://www.datapower.com/extensions"
xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
extension-element-prefixes="dp"
exclude-result-prefixes="dp"
version="1.1">
<xsl:template match="/">
<xsl:variable name="url" select="dp:variable('var://service/URI')"/>
<xsl:variable name="id" select="substring-after($url,'/projects/')"/>
<soapenv:Envelope
xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:dem="http://soap.example.com/demoService/">
<soapenv:Header/>
<soapenv:Body>
<dem:deleteProjectRequest>
<dem:id><xsl:value-of select="$id"/></dem:id>
</dem:deleteProjectRequest>
</soapenv:Body>
</soapenv:Envelope>
<dp:set-variable name="'var://context/rest/soap-action'"
value="'http://soap.example.com/demoService/deleteProject'"/>
</xsl:template>
</xsl:stylesheet> |
(10) call-demo-service.xsl変換: 前に示した通り、call-demo-service.xslスタイル・シートがSOAPペイロードをバックエンドに送信するために、また利用されます。
DELETEリクエストをWebSphere DataPowerに送信するには、このコマンドを使用してください。
curl -X DELETE http://DPHOST:8501/projects/2
まとめ
この記事ではIBM WebSphere DataPowerがどの様にWeb 2.0空間に適合するかを説明しました。
また、厳密なRESTとはどの様なものであるかについての定義を提供し、WebSphere DataPowerにより公開されるRESTのために使う推奨パターンを記述し、WebSphere DataPowerドメインのエクスポートとDemoService というWebサービスのバックエンド・アプリケーションによる総合的な例を含みました。
厳密なRESTとは何であるか、また、厳密なRESTサービスをWebSphere DataPower上で開発するにはどうすればできるかを理解いただけたと思います。あなた自身のWeb 2.0アプライアンスを構成することができるはずです。
ダウンロード | 内容 | ファイル名 | サイズ | ダウンロード形式 |
|---|
| Code sample | 2009-2-18_REST-DP-Files.zip | 5.1 MB | HTTP |
|---|
参考文献 学ぶために
議論するために
著者について  | 
|  | Robert R. PetersonはIBM Software Services for WebSphereのEnablementチームに所属しています。将来のIBMソフトウェア・システムのための戦略的なPoC(Proof of Concept)を実装するために世界を旅しています。数多くの技術書と論文を出版し、講演でも数多くの発表を行い、エンタープライズ・システムに関するいくつものUS特許を出願しています。著者のウェブ・サイトは こちらです。 |
記事の評価
|