RESTはWebAPIの代わりにはならない

Posted filed under Ruby on Rails.

Photo by Pulpolux !!!  bobchinさんの日記から「やっぱRESTは厳しいのかな?」。  RESTでは、リソースに対して一意のURLに、これって結局データストレージとして使えるっていうだけなんだと思います。MVCでいうmodelの部分。  これは、これでとても大切な部分なのですが、モデルを検索したり、いろいろ機能をRESTで提供するのは、うまくいかないと思います。  Railsだと、create, show, update, destroyメソッドはいいのですが、index(list)メソッドをXMLで返すようにしても、あまりうまくいかないケースが多いと思います。1画面に出る情報が多岐にわたるので、きれいに表現できないんですよね。

AtomPPのエラー処理

Posted filed under Ruby on Rails.

Photo by JosephH  先日の「レスポンスコードでステータスを判断するとFreeSpotとかで問題にならない?」で、たけまるさんから、詳しいお返事をいただきました。 たけまる / AtomPub のエラー処理について  AtomPPは全然わからないので、詳しい方に返事をいただけて光栄です。 たけまるさんのhikiは、GDataを調べてる時に、Google経由で何度も参考にさせていただいてます。  残念ながらWebDB+Pressは日本を離れるときに全部処分してきてしまいました。  やはりAtomPPでは、エラーの規定はないのですね。ほかのRFCで拡張されているのかなと思ったのですが、それもないのですね。  エラーの内容を返すときに、Atom Entry形式を使うか、errorタグで返すかが迷うところです。ブログのAPIを見ているとerrorタグで返しているケースが多いように感じます。

Apache(mod_rails)とmongrelでHTTPレスポンスヘッダに特定の値を返す

Posted filed under Ruby on Rails.

Photo by icanteachyouhowtodoit レスポンスコードでステータスを判断するとFreeSpotとかで問題にならない?からの続き。  ステータスコードで200が帰ってきたときに、ほんとに自分が通信したいサーバから帰ってきたかを検証する方法を考えてみました。  ほんとに相手のサーバを認証したい場合はSSLを使うべきですが、そんなに大事にしたくない場合は、HTTPレスポンスヘッダに特定の値をセットすることで、相手を特定できるのではないかと思います。  Railsのbefore_filterなどでresponse.headersをセットしてもいいのですが、これだとcacheに入った場合など、Railsを通らないときには、ヘッダが追加されません。 そのため、mod_railsの場合はApacheで、mongrelの場合はmogrel内でヘッダにセットする必要があります。  Apacheでは、Headerディレクティブでヘッダを書き換える事ができます。これを使う場合にはmod_headersを有効にしてください。 <VirtualHost *> …. Header set X-AppName sticka </VirtualHost>  mongrelの場合には、config/environment.rbに下記のコードを追加します。 if defined?(Mongrel) && defined?(Mongrel::Rails) class Mongrel::Rails::RailsHandler alias process_without_appname process def process(request, response) response.header[‘X-AppName’] = ‘sticka’ process_without_appname(request, response) end end end  これで、開発で使っているmongrelでも、実環境のApacheでもHTTPレスポンスヘッダのX-AppNameにはstickaが設定されます。  外部からAPIをアクセスする際には、X-AppNameを検証することで、プロキシなどによって勝手にリダイレクトなどをされても、それを検出することができます。

レスポンスコードでステータスを判断するとFreeSpotとかで問題にならない?

Posted filed under Ruby on Rails.

Photo by Paco CT いま、Sticka用などに外部からデータの更新と参照をするためにWebAPIを計画しているんだけど、WebAPIと一口に言っても、いろいろなプロトコルがあって、どれを採用するかでとても悩み中。 候補になっているのは下記の4つ。 RESTful (Rails) XML-RPC AtomPP GData  Railsだけを考えるなら、サービス全体をRESTfulにして、HTML以外にXMLも返す様にしておけば、外部から使うのも比較的容易。Rails同士ならActiveResourceも一応使えるし。ただ、Rails以外でクライアントを作るのがメンドクサイ。また、実際問題、HTMLのコントローラとAPI用のコントローラを一緒にするのは難しいケースもあるので、一つのクラスでHTMLもAPIもとはなかなか行かない。  サービスをRESTfulにしてXMLを返すのはいいけど、結局APIは別に用意しなきゃ行けない予感。  2つ目はBlogの編集などで採用されているXML-RPC。ほとんどのBlog engineが採用しているので、APIでの採用率はとても多い。でも、XML-RPCは通信方法の規定だけなので、APIのメソッドについては自分で規定するする必要あり。メソッド名のスタンダードはきちんとしていないため、XML-RPCでAPIを作ってもクライアント側も独自に実装する必要あり。MT互換のAPIとかもできるけど、ダサイ。  本命は3番のAtomPP。MT, WordPressなど、最近のBlog engineでもサポートされている、プロトコル。リソースへのCRUDをAPIとして実装するならかなりいい。ただ検索などのAPIは規定されていないので、この辺については独自で拡張する必要あり。  一番の問題はエラー詳細を返すフォーマットについて規定がないこと。HTTPのレスポンスコードだけで返すと、エラー詳細が分からないんだけど、それを渡す規定がない。あと、FreeSpotなんかで、アクセスすると初回アクセス時にどのページにアクセスしてもログインページなどに飛ばされるようにってるけど、そういう環境では、APIにPOSTして200が帰ってきても、実は届いてなかったという事が考えられる。  そもそも、そういう時には「407 Proxy Authentication Required」とか、別のレスポンスコードを返して欲しいのだけど、実際そうなってないので、なんらかの対策を考える必要がある。XMLのタグかHTTPヘッダで必ずシグニチャーみたいのを入れるとか。  AtomPPのエラー詳細と、ステータスコード、みんなどうしてるのかなぁ。知っている人、情報お願いします。  AtomPPとRSS2.0をベースに拡張したGoogleのAPIフォーマットが4番目のGData。 Googleで使われているAPIなので、現実的なメソッドが用意されている。検索とかエラーとか。ただ、認証方法はGlientLoginかAuthSub。WSSEじゃない。  GDataがいいかなぁ。AtomPPに独自タグを入れるか。まようなぁ。