まとめ
メニューを開く-
やっぱりRESTとかいってる人らはGUIから背を向けるんだろうか？静的な見た目はいくらでもGUIに近づけられるけど、リソースやURLとの絡みを考えると普通のGUIのものすごく小さな「サブセット」になる感じ。 -
ああそうか。RESTは「紙芝居の定式化」だ。
-
RDBと同じで、理論的に厳格な枠組みがあること自体はいいんだが、それでヤレルことが増えるとかいうことは全くなくて、どちらかというと「ここまでしかやれない」を明確化したみたいな。
-
しかしWebブラウザでユーザに晒される部分にそういう厳格な枠が有る場合、客のやりたいこととの刷り合わせは大変だったりしないんだろうか？
-
@naka_aki_spl RESTはここ2年ぐらい取り組んでみたのだけど、結論としてはRESTで扱えるデータには制限が多すぎて、よほどシチュエーションを限定しないと使い物にならないという感じでしたね -
業務アプリとかなら「もまえらのやりたい業務をリソースという切り口で再構成したらこうだべ」と高らかに宣言(ｗｗ)するという手も(原理的には)有るけど、Webチャラチャラ用途だとそれも難しいのでわ。
-
流行（？)したWeb2.0が不可思議だったのは、方向性の全然違う技術とかも全部いっしょくたにソレを名乗ったって点かなと。AjaxとRESTって違いすぎない？
-
(Ajaxで裏でREST鯖を叩く、とかいう「合わせ技」はもちろん有るが。)
-
アーキテクチャとしてRESTを眺めると、正規化したRDSMSの表をJOINなしで扱うような不便さ、といえばいいだろうか。
-
@nagise やっぱそのへんの位置づけになるわけですよねえ…＞REST。状況に応じて「REST度」を匙加減するってな感じじゃね？と思います。状況というのは例えば顧客との仲の良さとか(ｗｗｗｗ
-
@nagise やっぱそのへんの位置づけになるわけですよねえ…＞REST。状況に応じて「REST度」を匙加減するってな感じじゃね？と思います。状況というのは例えば顧客との仲の良さとか(ｗｗｗｗ
-
(再掲)RESTな人らが言う「勝利(したぞ)」とやらの基準が、一般人には判りにくい件。まさか単なるセールストークじゃ有るまいよ？
-
RESTではデータをURLで一意に特定するわけだけど、これはRDBMSのユニークキーの考え方と同じだからさほど難しくない。このデータを意味するURLに対し、HTTPのメソッド、GET、POST、DELETE、UPDATEで操作を行うというのが骨子
-
GETをするにあたって、RDBMS的なJOINをしちゃうとRESTが破綻しちゃうので、厳密にRESTを行うなら必要なだけリクエストを投げなきゃいけない。となると、性能問題に容易にぶちあたる
-
システムのフレームワークとしてRIA的なフロントエンドとバックエンドをつなぐプロトコルとして用いると、どうにも不便というかメリットがなく、デメリットばかりという感触だった。
-
@nagise あとトランザクションどーすんでしたっけ＞REST。トランザクションの味噌は複数更新処理のワンパック化だけど、HTTP一回で完結する義務があるなら、Txの代用品としてのリソース設計が凄まじいパズルになりそうな気が？？
-
@nagise あとトランザクションどーすんでしたっけ＞REST。トランザクションの味噌は複数更新処理のワンパック化だけど、HTTP一回で完結する義務があるなら、Txの代用品としてのリソース設計が凄まじいパズルになりそうな気が？？
-
じゃあRESTがメリットになるシチュエーションってなんだって話なんだけど、RESTを通した通信のサーバとクライアントが別人のようなシチュエーションじゃないか、と思ってる。Web越しにAPIを提供するようなシチュエーション。XML-RPCとかのシチュエーションに近い状況
-
やっぱり該当本を買って熟読すると判るんだろうか？＞REST(のすばらしさ(棒読み
-
@naka_aki_spl Webだと楽観排他が主になりますね。悲観的排他をする場合は、ロックを取得してから更新をするような手続きを踏まないといけないんじゃないかな。WebDAVみたいに。
-
-
@t_wada 罠なんですか？なんか「これはいい」的に言われるプレゼン資料とか見ると、しばしばいかにもGPPDをCRUDに対応付けるような表が載ってたような記憶がありますが…？
-
あとはリソースを表すURLに対して、メソッドが非対称になるのがイマイチ嬉しくないところで。JOINした状態のデータを表現するURLがあったとして、そこにDELETEを投げたらどのように動くべきか?
-
Content from Twitter
コメント