Hatena::ブログ(Diary)

yvsu pron. yas このページをアンテナに追加 RSSフィード

2007-06-30

RESTful WebService

tugboat.GTD Adobe AIR版の開発スタート

yosuke.hara's weblog

tugboat.GTD Adobe AIR版の開発に私も参加します。AIRクライアントtugboat.GTDサービスとは、RESTful WebServiceでつなぐことになります。このRESTful WebServiceの機能は、汎用化されてSeasar2.5にマージされることになると思います。

RESTって何って方は、こちらを参考にしてください。

http://yohei-y.blogspot.com/2005/04/rest_23.html

RESTって一口に言っても、ユーザインターフェースサービスの二つの部分に分かれるのではないかと思います。サービスというのは、WebService意味で使っています。もちろん、SOAPではなく。

せっかくなので、S2RESTの仕様を考えて見ます。書くのは次のエントリで。

S2REST

S2RESTで呼び出されるのは、Serviceクラスです。serviceパッケージに入っていれば、呼び出せるようにしようかなと思っています。Serviceクラスの名前は、リソース名 + Serviceになります。クライアントは、/リソース名/で呼び出します。

HTTPのメソッドとServiceクラスのメソッドの関係は次のようになります。

HTTPService
GETget
POSTcreate
PUTupdate
DELETEdelete

ただし、putとdeleteは、POSTを使ってformパラメータにhiddenで_methodを追加し、put, deleteを渡すこともできるようにする予定。

は、まぁいいかなと思いますが、条件付検索が難しいですね。

GET /リソース名/?パラメータ1=値1&パラメータ2=値2だったら、パラメータ1,パラメータ2をプロパティに持つDTOマッピングする感じかな。XxxService#get(XxxServiceGetDto dto)

同じに見えるリソースでも表現が異なる場合があります。例えば、従業員データを返す場合と、従業員+部署のデータを返すようなケースです。このような場合は、

GET /emp/withDept/

をEmpService#getWithDept()にマッピングすればよいのかなと考えています。

HTMLクライアントサービスを区別するためにGET /service/リソース名/にしたほうが良いかも。なぜなら、http://.../ユースケース名/xxx.htmlなどと区別するため。

戻り値の形式は、Acceptヘッダによって切り替える予定ですが、デフォルトは、Atomになると思います。

ビリーズブートキャンプ

今日は、応用編。基本編よりやっぱきつい。初心者なのに、ビリーバンド使っているのでさらにきつい。腹筋のところで起き上がれないんだけど。

szk-takanoriszk-takanori 2007/07/03 00:33 たかのりです。
便利そうですよね > S2REST
私もS2Axis2使って、近いことをやろうと思案したことがあります。ちょっと、思いついたことですが、

・GETに対応するメソッドは「find」の方が安全
getは、setter/getterの処理と被る可能性が高いため。S2.5で、インタフェースを無くす方針を考えると、findの方がAOPの適用時などに便利そうです。

・条件付検索
パラメータが1つならば、getBy<パラメータ名>が呼ばれると良いと思いました。2つ以上ある場合は、DtoもしくはEntityにマッピングが利便性が高そうですね。

・配列対応
id=1&id=2&id=3 というのがあれば、setId(Intger[] ids)なんてメソッドにsetされると便利だと思います(Dtoにsetする場合や、GETに対応するメソッドを呼び出す場合)。

・JSR 311: Java API for RESTful Web Servicesへの対応
全然中身見ていないのですけれど(汗)、仕様は確認しておいた方が良いかもしれません。思いつきですが。アノテーションでリソース名やMIMEの設定などができるそうです。

とりあえず、思い付いたところまで。