Hatena::Diary

いたわさににほんしゅ RSSフィード

2008-01-18

FIFO なデータ構造へのアクセスはどうするんだろう

RESTful な HTTP の使いかたという文脈で、特に構造を持たないような集合をリソースとして、CRUD を行うという話はよくある。(cf. http://yohei-y.blogspot.com/2005/04/rest-5-get-post-put-delete.html)

では、キュー(FIFO なデータ構造)を扱うにはどのように構成したらよいのか? と考えはじめて分からなくなった。

  1. head には突っ込むことだけが出来る
  2. tail からは取り出しだけが出来る
  3. その他の要素には(管理とかは置いといて)アクセスできない

PUT/DELETE の羃等を知らなかったときには、キュー(queue.hoge という名前だとする)をリソースと見立てて、

  1. PUT /queue.hoge で head に突っ込む
  2. DELETE /queue.hoge で tail から取り出す

でいいのかなぁ、と思っていた。が、PUT と DELETE を羃等にしようとすると、この構成ではダメ。

「RESTful Web サービス」をパラパラながめてみたけど、わからん。あまり良い案が思いうかばないのだけど、いまの頭にあるのは以下。

キューではなくて、head/tail をリソースと見立てる。

  1. POST /queue.hoge/tail で突っ込む
  2. POST /queue.hoge/head で取り出す

一般的に、構造を持ったリソースに対する、リッチな(内部が隠蔽された)操作は、どのように HTTP へマップすれば良いかというのは難しい質問になりそうなので置いとく。

2007-02-23 追記

はてなブックマークで id:teahut さんより情報をいただいた http://b.hatena.ne.jp/teahut/20080118#bookmark-7127896

また、コメントにて、id:m_seki から "「queue への依頼を表す伝票」リソースの新規作成とかんがえて POST で" 、id:yohei さんからは "subscription 導入が好み" というご意見と設計の指針をいただきました。ありがとうございました。

個人的には、何度も行き来するのは無駄な気がするので、単純に POST を使うのが好みかもしれない。もう一度、ML スレッドを読みこんでみて、制限を考えることにする。

m_sekim_seki 2008/01/18 19:52 再掲。RESTはあんまり興味ないのですがenqもdeqも「queueへの依頼を示す伝票」リソースを新規作成すると考えるとPOSTでよいように思います。deqが返すURLは取り出した要素へのポインタかなあ。要素が要らなくなったらDELETEするとか。

yoheiyohei 2008/01/19 01:10 ブックマークで id:teahut さんがコメントしている手法が一般的な感じですね。個人的には subscription resource を新規に導入する方が好みです。

一般的なリソース設計の定石としては「HTTP メソッドを追加したくなったらリソース設計を見直し、必要であればリソースを追加する」というのがあります。 HTTP には結局のところ 4〜6個のメソッドしかなくて、それらを拡大解釈することはできないので、GET/POST/PUT/DELETE/HEAD/OPTIONS が無理なく使えるようにリソース/URIを設計する方が良いようです。

ただ、リソースの設計は難しいんですよね。職人芸的なところがたくさんあるし…

スパム対策のためのダミーです。もし見えても何も入力しないでください
ゲスト


画像認証

トラックバック - http://d.hatena.ne.jp/ita-wasa/20080118/1200623188