ウェブの原則とアーキテクチャ

きしだൠ(K1S) @kis

@nsiena Google DocsやGMailはどういう位置づけでしょうか？

@nsiena

@kis UI が使いにくいと感じるのであまり使ってないですが。知っている範囲では、十分にウェブ的な気がします。たぶん。

@nsiena

Ajax アプリでは。ブラウザに表示されるウェブページは UI リソースで、入れ物だけ。Ajax などでアクセスされているリソースをマッシュアップしているだけ。という意味で、ウェブ的と見ている。

@nsiena

公開される情報の塊が (ウェブアーキテクチャでいうところの) リソースとして定義されていて、これらのアクセス方法がウェブらしくあればウェブ的。なのかな。

@nsiena

UI 上で動的に構築されているスナップショットがアクセス可能であるべきならば、それが URI を持つべき。という意味では、何をリソースとみなすのかにも依存する。

きしだൠ(K1S) @kis

@nsiena MSもブラウザベースでOffice作るようなので、ウェブがアプリケーションプラットフォームとして限界があるようには今のところ思えません。OCXのようなものの必要性ということでしょうか？

@nsiena

@kis 実現方法によるので、見てみないと断定できないかな。少なくとも、操作のコマンド/結果を送受信する、という作り方だとすればウェブ的ではないと思う。URI の先にあるものはリソースであって、処理機能であるべきではないので。可能ということと、どうあるべきかということは違うし。

@nsiena

@nsiena もしかして、Google Docs とかもそういう作りなのかしら。なんとなくの憶測だけど。だとすると、部分的にのみウェブ的、に訂正かな。

きしだൠ(K1S) @kis

@nsiena 「処理機能であるべきではない」というのがウェブ的ではないというのがよくわからないです・・・

きしだൠ(K1S) @kis

@nsiena post/deleteなどのHTTPメソッドはweb的ではないということですか？

@nsiena

@kis HTTP メソッドの DELETE, POST, PUT などは統一インタフェースとして既定されたもので、正当なもので。要求ボディに要求メソッドと相容れない操作が書かれているとか、特定の URI が何らかのの操作を表現しているとかは不自然なことが多いと。

@nsiena

@kis 例えば。GET /hoge?method=delete とか。/delete?id=hoge とか。リソースは情報の塊とでもいうような存在で、それに対する操作が HTTP メソッドですよね。

NISHIMOTO Keisuke @keisuke_n

@nsiena ようするに統一されたものが欲しい、というのが要約ですね(要約しすぎ＞＜

@nsiena

@keisuke_n REST の四つの基本性質のうち、統一インタフェースに限ってだけ言えば、(ほぼ) 統一され他ものが欲しい、でいいです ^^;

きしだൠ(K1S) @kis

@nsiena HTTP上でのRPCはweb的ではないということですかね。

@nsiena

@kis RPC 的な使い方は、ウェブ的ではないと思うです。Web Socket 的な、持続的ストリームを使った漸次的なステートレス通信をするのも。/ Comet のような、応答を遅延させることでサーバからのプッシュ型通知はやり取りされる内容による、かな。

@nsiena

HTTP の通信のしかただけでなくて、リソース足りうるものがリソースとして定められているかとかも。/ ハイパーテキストというアプリケーション特性と、HTTP で狙っている通信特性と。

きしだൠ(K1S) @kis

@nsiena 現実的にはファイヤウォールなんかでHTTP以外に確実に通信できるプロトコルがなくなったりしてるので、HTTPを使うのは仕方ないと思うので、HTTP上でRPCを規定したら「ウェブとは違う、プログラムに適したプラットホーム」を作ったことになりますかね。

@nsiena

@kis 動くけど abuse なのでないかしらん、という立場です。/ 大ウェブサービスはウェブとは違う世界を組み上げてる感じで。そして、HTTPボディを見て選別したりする、ウェブアプリファイアウォールが出てきて、更にスタックを積み上げる羽目になる、と ^^;

きしだൠ(K1S) @kis

@nsiena webは15年前の素朴な状態に戻って、アプリケーション用の別のものをたてるべきということ？

@nsiena

@kis そこまで極端な立場ではなく。HTTP の特性に合わない通信を無理矢理したり、リソースとしても意味がないような何かを無理にリソースのように扱ったりせずに。それに適したプロトコルを別途策定して *併用* すればいいんでないの、というくらいかしらん。

@nsiena

@nsiena HTTP と FTP を併用して。HTTP ではしにくい対話的な操作は FTP でして、リソース (ファイル) の CRUD 程度は HTTP でできる、みたいな。

きしだൠ(K1S) @kis

@nsiena HTTPとは別のプロトコルをHTTPと併用するというのは、よほどHTTPでアプリケーションが組めないということがないと難しいでしょうねぇ。

@nsiena

@kis そういう用途の多くは、Web Socket でカバーできるのでないかなと期待。で、うまく使い分けようよ、と。

@nsiena

@kis 危惧するのは。今度は何でも Web Socket でやろうとしたり、リソースとして不適切なものが氾濫したり。リソースとすべきものがリソースとして提供されなかったり。切り分けられるようになるのならば、ちゃんとウェブらしくモデリングしてほしいな、とも。