RESTful Web Service
Shinji KONO
珍しく、Web Service の本を読んでみました。Leonrad Richardson
かぁ。最初の3章がつまらないです。訳は割とまともだと思いました。
1-3章は読まなくて良いようです。4-6章は同じことを繰り返し書
いてる。1章で済むんじゃないかと思いました。7章はコードだけ
なので読まなくて良いし。9章のXMLのencodingがHTMLに優先しない
とか、text/xmlとするとencodingを無視されるとか、そんな話の方が
面白かった。
Representational State Transfer という用語自体の方が、この
本よりわかりやすいんじゃなかろうか?
URIにリソースを指し示す十分な情報をいれる
URIをRPCの単なる入口として使って statefull にしない
Cookie を使わないで、authentication や client side stateを使う
なんだけど、Stateless にする直接的な利点は Caching だけ?
良くわからんな。
なので、元ネタなはずの、Architectural Styles and the Design
of Network-based Software Architectures, Roy Thomas Fielding
も読んでみたんですが、こっちも、4章までは読む必要のない本な
のね。うーん、ほとんど同じか。要するに、URI で指し示すデー
タを操作すると言う Software Architcture として、Web を使い
ましょうってことなのね。
RESTful の方はプログラマが書いた本という感じ。向うの人って
図を書くのがへただよね。92ページの図の差は、図を見ただけじ
ゃわからないと思う。そもそも図がほとんどないし。文章とプロ
グラム、そして、HTML等の例示だけで話が進むので読みづらいで
す。6章だけ読めば良いんじゃなかろうか?
個人的には Ruby あんまり好きじゃないので、Ruby/ Ruby on Rail
な例だけが出て来るのは辛かったです。
Fielding 博士の方も字ばっかり。むぅ。なんかさぁ。データとか
グラフとかないの? D論なんだよね? もちろん、HTTP 1.1を作った
という実績は凄いと思うし「だからぁ、RESTful に使ってよ」と
言う設計者の意図はわかるんだけど。
でも、実際に、RPC としてHTTPを使うのと、URIに意味を持たせるのと、
そんなに違うかな? もう少し、URIやHTTP methodに具体的な意味が
あれば、途中のキャッシュなりに色んな工夫が出来るとは思うけど。
WSDL, WADL, XML, XHTML, MIME, UTF-8, ISO-8859-1 このWWWの
バベルの塔を作ってしまったのは仕方がない。それにあんまり係わる
必要がない僕は幸せだと思いますが、どっぷりはまっている人は
可哀想だ。と、そんな風に思いました。
---
Shinji KONO @ Information Engineering, University of the Ryukyus
河野真治 @ 琉球大学工学部情報工学科
Yasushi Shinjo
In article <3993671...@leo.ie.u-ryukyu.ac.jp>
ko...@ie.u-ryukyu.ac.jp (Shinji KONO) writes:
> 珍しく、Web Service の本を読んでみました。Leonrad Richardson
> かぁ。最初の3章がつまらないです。訳は割とまともだと思いました。
学生に貸したら帰って来ないなあ。ちゃんと読んでいるんだろうか。
> Representational State Transfer という用語自体の方が、この
> 本よりわかりやすいんじゃなかろうか?
> URIにリソースを指し示す十分な情報をいれる
> URIをRPCの単なる入口として使って statefull にしない
> Cookie を使わないで、authentication や client side stateを使う
>
> なんだけど、Stateless にする直接的な利点は Caching だけ?
> 良くわからんな。
stateless の方が、サーバの実装としては、楽です。関数的な動き
でよいので。stateless という話と、URI を使うという話は独立し
た話とも言えます。カウンタみたいなの作るとどうなるか。
> でも、実際に、RPC としてHTTPを使うのと、URIに意味を持たせるのと、
> そんなに違うかな?
前に考えた時には、これは REST ではダメで SOAP が必要だと思っ
たのは、、、忘れた。オブジェクトの初期化の所だったかな。
今ある SOAP を REST にしようとしたらダメだという話だったんだ
けど、なんだったっけなあ。オブジェクトの初期化の所だったかな
あ。stateless がどうのという深い話ではなかった気がするが。
> WSDL, WADL, XML, XHTML, MIME, UTF-8, ISO-8859-1 このWWWの
> バベルの塔を作ってしまったのは仕方がない。それにあんまり係わる
> 必要がない僕は幸せだと思いますが、どっぷりはまっている人は
> 可哀想だ。と、そんな風に思いました。
複数あつかってなんとかしようと思うと辛いでしょうね。１個しか
使わないなら、はまっていても気が付かないからある意味せなの
では。
＼＼ 新城 靖 （しんじょう やすし） ＼＼
＼＼ 筑波大学 電子・情報 ＼＼
Shinji KONO
In article <YAS.08Ma...@kirk.is.tsukuba.ac.jp>, y...@is.tsukuba.ac.jp (Yasushi Shinjo) writes
> > WSDL, WADL, XML, XHTML, MIME, UTF-8, ISO-8859-1 このWWWの
> > バベルの塔を作ってしまったのは仕方がない。それにあんまり係わる
> > 必要がない僕は幸せだと思いますが、どっぷりはまっている人は
> > 可哀想だ。と、そんな風に思いました。
>
> 複数あつかってなんとかしようと思うと辛いでしょうね。１個しか
> 使わないなら、はまっていても気が付かないからある意味せなの
> では。
いや、全部使わないとダメなところが、「バベルの塔」なわけで...
Yasushi Shinjo
fj.comp.distributed もクロスポストに追加してみました。
In article <3993685...@rananim.ie.u-ryukyu.ac.jp>
ko...@ie.u-ryukyu.ac.jp (Shinji KONO) writes:
> > > WSDL, WADL, XML, XHTML, MIME, UTF-8, ISO-8859-1 このWWWの
> いや、全部使わないとダメなところが、「バベルの塔」なわけで...
まあ、WSDL と XML は使うのが普通でしょうが、後はあんまり関係
ないなあ。
WSDL は、避けようとおもえばけっこう避けられます。クライアン
トだけなら特に。その変りに、XML を直にたたくわけです。でもこ
んなことするら、REST の方がいいやってことになって、REST になっ
たという話か。
で、１つ、SOAP にできて REST には今の所できないのを思い出し
ました。スタブ生成器です。WSDL2Java とか、WSDL からスタブを
生成する機能はかなり便利です。そのレベルだと、バベルの塔も見
ないで済むし。（スタブ生成器つくる人はお疲れ様。）
REST 用のスタブ生成器って存在しないですよね。
存在するなら、スタブ生成器に何を食わせるんでしょうか。
Shinji KONO
In article <YAS.08Ap...@kirk.is.tsukuba.ac.jp>, y...@is.tsukuba.ac.jp (Yasushi Shinjo) writes
> で、１つ、SOAP にできて REST には今の所できないのを思い出し
> ました。スタブ生成器です。WSDL2Java とか、WSDL からスタブを
> 生成する機能はかなり便利です。そのレベルだと、バベルの塔も見
> ないで済むし。（スタブ生成器つくる人はお疲れ様。）
REST は、URIのconventionみたいなところがあるので、そういう
話とは直交しているでしょうね。
> REST 用のスタブ生成器って存在しないですよね。
> 存在するなら、スタブ生成器に何を食わせるんでしょうか。
今だと、Ruby on Rail みたいなものになるので、データベース
スキーマということになるでしょう。
Yasushi Shinjo
In article <3993686...@rananim.ie.u-ryukyu.ac.jp>
ko...@ie.u-ryukyu.ac.jp (Shinji KONO) writes:
> > で、１つ、SOAP にできて REST には今の所できないのを思い出し
> > ました。スタブ生成器です。WSDL2Java とか、WSDL からスタブを
> > 生成する機能はかなり便利です。そのレベルだと、バベルの塔も見
> > ないで済むし。（スタブ生成器つくる人はお疲れ様。）
>
> REST は、URIのconventionみたいなところがあるので、そういう
> 話とは直交しているでしょうね。
理論的にはそうです。でも実際問題、REST のためのスタブ生成器
が存在しないなら、スタブ自動生成の機能を使いたいなら、SOAP
を使えということになります。
> > REST 用のスタブ生成器って存在しないですよね。
> > 存在するなら、スタブ生成器に何を食わせるんでしょうか。
>
> 今だと、Ruby on Rail みたいなものになるので、データベース
> スキーマということになるでしょう。
データっぽい定義で、メソッドが生成されるのは、違和感がありま
す。でも、そもそも論としては、メソッドではなくて、データをア
クセスして使えという思想なのかな。そこまの思想はないか。
単に CGI で query string で引数をとるというくらいのメカニズ
ム優先で。
REST と SOAP を比較したページとして、こんなの見つけました。
ついでに、JSON も書いてあります。JSON は、XML ではなくて
JavaScript の文法でデータを飛ばす方法です。
http://www.xmlconsortium.org/wg/web2.0/teigensho/4--REST-SOAP.html
ここの表の「開発ツール」の所が、SOAP は○になっています。後は×。
関係ないですが、Firefox 3.0 では、SOAP サポートが消えてREST
は入るとか。もともと大したサポートではなかったけれど。