rest-discuss ML の message queues スレッド

Web

http://comments.gmane.org/gmane.comp.web.services.rest/6149

最初のメッセージではこんなことを書いている

  • まず、ActiveMQ の(その当時の) REST API の抜粋: POST で in, GET or DELETE で out
  • GET が read-only なのは、REST じゃなくて HTTP
  • キューを表す URL への DELETE は、キュー全体の削除を意味する
  • これはリストに投げたのは、面白いケースで、即座にはより良い方法を思いつかなかったからだ

このエントリでは、キューへ突っ込むのを in, 取り出すのを out と書くことにする。POST/GET は HTTP メソッドのこと。

次のエントリでは、POST-GET-DELETE という提案がある。http://permalink.gmane.org/gmane.comp.web.services.rest/6150

  1. POST /queue/
    • 201, Location /queue/snapshotIDxxxx
  2. GET /queue/shapshotIDxxxx
    • 200, state of the snapshot, with links to elements
  3. DELETE /queue/snapshotIDxxxx/1
    • 200, deleted resource

これはトランザクションモデルである。その意味は、マルチコンシューマーで、スナップショットを作ると、キュー内の全て(everything in the queue) は消える

全ては消える、の意味が分からん。2番目の GET で頭から数個のメッセージを返すとすると、複数コンシューマーが並列アクセスすると無駄が発生しそうでちょっと嫌なかんじ。out をトランザクショナルにするところは参考になる。というか嬉しい。reliable-msg では、トランザクションに入ったメッセージを他のコンシューマーに見えないようにしているので、そこは HTTP でも入れておきたい機能。最低限、begin-out-commit という程度はサポートしたい。2 番目が GET なのがちょっと微妙か。

話が逸れるが、in 側では、サーバ側で GUID を発行するシーケンスもサポートは必要かもしれない。これは、ActiveMQ の send to queue http://activemq.apache.org/restful-queue.html で自然かな。リソース中心でいくなら、GUID をリソースにするのが良いな。

その後、HTTPLR http://www.dehora.net/doc/httplr/draft-httplr-01.html#rfc.section.9 が引用される。が、メッセージ持ってくるだけなのに、3 回もやり取りするの嫌だ、と一蹴(?)されてる。その流れで、「クライアントがちゃんと処理できたかを伝えなくてはいけないよね」といっている。そこでは ack を送信しているけど、いわゆるトランザクションのコミットだな。

Re: Message queues
The sanest approach to modeling queues I know of over HTTP is syndication technology; ie force the data structure towards a list. And if you need to do pubsub, give everyone their own URL to pop.

訳: 知っているかぎり、HTTP 上でキューをモデル化する一番まっとうな方法は、データ構造をリストだとする syndication テクノロジーだ。pub/sub したかったら、ポップするために、それぞれに固有の URL を与えれば良い。
http://article.gmane.org/gmane.comp.web.services.rest/6164

キューの取り出しの競合が考慮されていない。ちょっと受け入れ難い。

Re: Message queues
> I don't see a single-request solution except to use POST or maybe PUT,
> and then it smells more like some flavor of POX or RPC.

Don't feel bad about it:

http://article.gmane.org/gmane.comp.web.services.rest/6189

といって、(結局?) Roy T. Fielding さんの引用を 3 つしている。1 つだけ引用。

Fielding Dissertation: CHAPTER 5: Representational State Transfer (REST)
Like most architectural choices, the stateless constraint reflects a design trade-off. The disadvantage is that it may decrease network performance by increasing the repetitive data (per-interaction overhead) sent in a series of requests, since that data cannot be left on the server in a shared context. In addition, placing the application state on the client-side reduces the server's control over consistent application behavior, since the application becomes dependent on the correct implementation of semantics across multiple client versions.

訳: 多くのアーキテクチャの選択と同様に、ステートレス性も設計のトレードオフである。不利な点は、[中略]ネットワークの性能低下につながるかもしれない。加えて、アプリケーションの状態をクライアント側に置くことは、一貫したアプリケーションの振る舞いに対するサーバーの制御を限定するので、多様なクライアントの種類に渡る意味論の正しい実装に依存するようになる。
http://roy.gbiv.com/pubs/dissertation/rest_arch_style.htm#sec_5_1_3

含蓄深いな。ちゃんと自分の問題を理解して設計しろ、と。まぁ、そりゃそうだ。
というわけでやりたいことをまとめよう。

  1. out: (複数クライアントの)競合が一番あるところなので、いきなり(1 つの request/response で)メッセージ取得ができるようにする
  2. out: トランザクションも使えるようにする、複数の out や、in/out 混在は「出来れば」くらいで、begin-out-commit のシーケンスは必要
  3. in: ひとつ入れる分には、out との対称性、簡単さを重視
  4. in: クライアント側で UUID(GUID) を発行しなくても良いように、サーバ側で発行できるようにする、これも「出来れば」かな

TODO: point to many は未だ