RESTful ツールキット

» Permanent link | |

昨年11月に Amazon Web Service から Simple Queue Service がリリースされた。

このサービスの持つインパクトについては江島健太郎氏の blog が最もよく記述されている。

いわく、エンタープライズ市場で醸成されてきたキューイング技術がAmazon によって非対称ポーリングモデルという形でパーソナルユースに取り込まれることにより、B2C ならずとも B2B の世界にも大きなインパクトをもたらすであろう、ということだ。この考察は素晴しいと思う。トラックバックを見ると、そのように感じた人も多いようだ。

Amazon のこのサービスがアルファギークの興味とうまく連携してこれまで想像もつかなかった応用を生めば、確かにとても面白い。

ところで Amazon Web Service の常だが、この Simple Queue Service も二つの API を持っている。一つは SOAP/WSDL であり、もうひとつが REST API だ。ただし、この REST API は肝心の REST 陣営からは評判が悪い。

BitWorking の Joe Gregorio が xml.com で SQS REST API の批判記事を書いている。

SQS REST API の最大の問題点は、オペレーション名を URI に埋め込んでおり、全ての操作を HTTP GET で実現しているところだ。REST では HTTP の GET オペレーションはリソースの状態変更してはならないのだが、SQS ではキューの削除まで GET でできてしまう。

ただし、Amazon 側からしてみると、そんなことは百も承知で全てのメソッドを HTTP GET で実現しているのだろう。彼らが GET を採用している本当の理由は、それが一番クライアントを作りやすいからだと思う。

GET ならブラウザさえあれば簡単に試すことができる。XSLT/XPath の document() 関数も URI を GET してくれる。wget を使えばコマンドラインからでもできる。ある URL を簡単に GET するための仕組みはすでに十分用意されているのだ。perl も ruby も python も知らないけど、おそらく GET が一番簡単だろう。

REST の概念は美しいし、共感するけれど、いざ実装となるととたんに難しい。それは現状で用意されているツール、ライブラリ、フレームワークのしがらみや制約からくるものだ。では、そこをサポートするツールがあったらどうだろう。具体的には任意の XML やバイナリを任意の URI に GET, POST, DELETE, PUT できる簡易ブラウザのようなイメージである。

RESTful なサーバ側フレームワークも重要だが、クライアントライブラリも同じように重要だと思う。