RESTのインピーダンスミスマッチ

非実在naka aki @naka_aki_spl

やっぱりRESTとかいってる人らはGUIから背を向けるんだろうか？静的な見た目はいくらでもGUIに近づけられるけど、リソースやURLとの絡みを考えると普通のGUIのものすごく小さな「サブセット」になる感じ。

非実在naka aki @naka_aki_spl

ああそうか。RESTは「紙芝居の定式化」だ。

非実在naka aki @naka_aki_spl

RDBと同じで、理論的に厳格な枠組みがあること自体はいいんだが、それでヤレルことが増えるとかいうことは全くなくて、どちらかというと「ここまでしかやれない」を明確化したみたいな。

非実在naka aki @naka_aki_spl

しかしWebブラウザでユーザに晒される部分にそういう厳格な枠が有る場合、客のやりたいこととの刷り合わせは大変だったりしないんだろうか？

なぎせ ゆうき @nagise

@naka_aki_spl RESTはここ2年ぐらい取り組んでみたのだけど、結論としてはRESTで扱えるデータには制限が多すぎて、よほどシチュエーションを限定しないと使い物にならないという感じでしたね

非実在naka aki @naka_aki_spl

業務アプリとかなら「もまえらのやりたい業務をリソースという切り口で再構成したらこうだべ」と高らかに宣言(ｗｗ)するという手も(原理的には)有るけど、Webチャラチャラ用途だとそれも難しいのでわ。

非実在naka aki @naka_aki_spl

流行（？)したWeb2.0が不可思議だったのは、方向性の全然違う技術とかも全部いっしょくたにソレを名乗ったって点かなと。AjaxとRESTって違いすぎない？

非実在naka aki @naka_aki_spl

(Ajaxで裏でREST鯖を叩く、とかいう「合わせ技」はもちろん有るが。)

なぎせ ゆうき @nagise

アーキテクチャとしてRESTを眺めると、正規化したRDSMSの表をJOINなしで扱うような不便さ、といえばいいだろうか。

非実在naka aki @naka_aki_spl

@nagise やっぱそのへんの位置づけになるわけですよねえ…＞REST。状況に応じて「REST度」を匙加減するってな感じじゃね？と思います。状況というのは例えば顧客との仲の良さとか(ｗｗｗｗ

非実在naka aki @naka_aki_spl

@nagise やっぱそのへんの位置づけになるわけですよねえ…＞REST。状況に応じて「REST度」を匙加減するってな感じじゃね？と思います。状況というのは例えば顧客との仲の良さとか(ｗｗｗｗ

非実在naka aki @naka_aki_spl

(再掲)RESTな人らが言う「勝利(したぞ)」とやらの基準が、一般人には判りにくい件。まさか単なるセールストークじゃ有るまいよ？

なぎせ ゆうき @nagise

RESTではデータをURLで一意に特定するわけだけど、これはRDBMSのユニークキーの考え方と同じだからさほど難しくない。このデータを意味するURLに対し、HTTPのメソッド、GET、POST、DELETE、UPDATEで操作を行うというのが骨子

なぎせ ゆうき @nagise

GETをするにあたって、RDBMS的なJOINをしちゃうとRESTが破綻しちゃうので、厳密にRESTを行うなら必要なだけリクエストを投げなきゃいけない。となると、性能問題に容易にぶちあたる

なぎせ ゆうき @nagise

システムのフレームワークとしてRIA的なフロントエンドとバックエンドをつなぐプロトコルとして用いると、どうにも不便というかメリットがなく、デメリットばかりという感触だった。

非実在naka aki @naka_aki_spl

@nagise あとトランザクションどーすんでしたっけ＞REST。トランザクションの味噌は複数更新処理のワンパック化だけど、HTTP一回で完結する義務があるなら、Txの代用品としてのリソース設計が凄まじいパズルになりそうな気が？？

非実在naka aki @naka_aki_spl

@nagise あとトランザクションどーすんでしたっけ＞REST。トランザクションの味噌は複数更新処理のワンパック化だけど、HTTP一回で完結する義務があるなら、Txの代用品としてのリソース設計が凄まじいパズルになりそうな気が？？

なぎせ ゆうき @nagise

じゃあRESTがメリットになるシチュエーションってなんだって話なんだけど、RESTを通した通信のサーバとクライアントが別人のようなシチュエーションじゃないか、と思ってる。Web越しにAPIを提供するようなシチュエーション。XML-RPCとかのシチュエーションに近い状況

Takuto Wada @t_wada

@nagise それは誤解ですよ。結果をリソースとして考えればいい。 GET/POST/PUT/DELETE を "RDBMS の CRUD" に対応させるというのは陥りやすい罠です。

非実在naka aki @naka_aki_spl

やっぱり該当本を買って熟読すると判るんだろうか？＞REST(のすばらしさ(棒読み

なぎせ ゆうき @nagise

@naka_aki_spl Webだと楽観排他が主になりますね。悲観的排他をする場合は、ロックを取得してから更新をするような手続きを踏まないといけないんじゃないかな。WebDAVみたいに。

Takuto Wada @t_wada

@naka_aki_spl @nagise にも #webtechbook をおすすめしますよw

なぎせ ゆうき @nagise

.@t_wada GETでJOINをする/しないの場合のURLのわけ方がスマートに行かなかったんですよ。何か解決策があるんですかね?

非実在naka aki @naka_aki_spl

@t_wada 罠なんですか？なんか「これはいい」的に言われるプレゼン資料とか見ると、しばしばいかにもGPPDをCRUDに対応付けるような表が載ってたような記憶がありますが…？

なぎせ ゆうき @nagise

あとはリソースを表すURLに対して、メソッドが非対称になるのがイマイチ嬉しくないところで。JOINした状態のデータを表現するURLがあったとして、そこにDELETEを投げたらどのように動くべきか?