サーバ側でWADLを使用してみる
WADL拡張機能を使用すると,リソースクラスとWADLファイルを作成するだけでサーバ側restletを構築できる
WADLはWeb Application Description Languageの略らしい.
SOAPならWSDLのところを,RESTならWADLということだろうか.
WSDLはかなり複雑なものとなっているようだが,WADLはRESTと同様,シンプルな仕様となっており,扱いやすい.
この辺が仕様のようだ.
Restletの配布物には,
あとは,
org.restlet.ext.wadl_1.0.jarが含まれており,これをクラスパスに加えると,org.restlet.ext.wadlパッケージのWadl拡張を使用できる. より具体的には,Resourceクラスを作成し,Wadlファイルにてサーバ構成を設定すれば,いきなりrestletとなる. 最初のサンプルとして作成したHelloResourceとParamResourceで構成してみる.
org.restlet.ext.wadl.WadlComponentに上記WadlファイルのURLを指定すれば(※),サーバ側restletとして起動する. ソースを見た感じ,Wadlファイルは複数指定できそう.
for (final String arg : args) {
component.attach(arg);
}
※ URLを記述すること.
org.restlet.Componentの場合は,ローカルの設定ファイルのみを想定していたので,単純なファイルパスでよかったが,WadlComponentの場合は,ローカルファイルでも"file:///...../hello.wadl"としなければならない.
WADLの厳密な仕様を知りたい場合は,http://research.sun.com/wadl/2006/10を辿ってXSD参照.
もっとおおらかに観て行くなら,
applicationが一つ
resourcesが一つ
resourceが複数
各resourceにmethodが一つ
となっている.
他にも要求回答の定義などもあるが,それは別途.
注意点としては,resources要素の属性baseがベースのURLとなり,resouce要素の属性pathはそのベースURLからの相対パスであること.
バグなのか仕様なのかよく分からないが,resources要素の属性baseの値は"/"で終るとどのresource要素にもマッチしなくなるので注意.
ベースURLやパスの末尾には"/"はいれず,パスの先頭には"/"をつけるというのがよさそうな雰囲気.
そして,リクエストのURLがresource要素のパスとマッチした場合,resource要素のid属性に設定したResourceクラスのFQCNが生成され動く.
このid属性の設定値に関する仕様はWADLのものではなく,Restlet特有らしい.
また,WadlComponentのJavaDocによれば,resouces要素に応じてバーチャルホストを生成して,マルチスレッドで動かすから,WadlComponentクラスやそのサブクラスはスレッドセーフにしておきなさいとのこと.
