REST http://ja.wikipedia.org/wiki/REST#.E5.8E.9F.E5.89.87
ステートレスだったからこそ、URL/Method/query などに必要十分な情報を持たせた。
WebSocket サーバの実装とプロトコル解説 http://d.hatena.ne.jp/Jxck/20120725/1343174392
// Client
var ws = new WebSocket("ws://example.com/", ["test", "chat"]);
ws.onopen = function() {
ws.send("test");
ws.onmessage = function(message) {
console.log(message.data); // test
};
}Socket.IO API 解説 http://d.hatena.ne.jp/Jxck/20110730/1312042603
// Client
var socket = io.connect('http://example.com');
socket.on('connect', function() {
socket.emit('msg send', 'data');
socket.on('msg push', function (msg) {
console.log(msg);
});
});https://github.com/flatiron/socketful#core-socketio-mappings
socket.emit('creatures', 'create', { id: 'bob' } , function(err, bob) {
console.log('created: ', bob);
};- WebSocket はステートフルである
- 確立したコネクション上では、基本的に message (HTTP でいう Body 相当)を送る
- Body に工夫をするのは WebSocket 上の独自サブプロトコルでしかない
server push
接続こそクライアントからだが、その後はサーバから Push 可能。 そして、サーバもクライアントから Push を受け取っている状態とも考えられる。 (HTTPとは違うコンテキストで) だから「双方向(bi-directional)」。
レイヤが違う
Web は 論文の共有なんかをモチベーションに始まった。 ドキュメントは Pull するものだった。 それを根底として、色々積み上げてきた HTTP のアーキテクチャにおいて、 REST は親和性が高かった。
でも、Push が可能になった時点で、 「アーキテクチャは延長ではなく変化」を迎えた。
REST を無理やり当てはめるより、積極的に別の方法を模索したっていいんじゃない？
wget で取得できない Web は壊れてる的なあれについて。 気持ちはわかるけど、そこで壊れてるのは、 「Web」ではなく「ドキュメント」だと思う。
リソース表現としてのドキュメントが、 URI, Method で取得できないと、 それを壊れてると言いたいのはわかる。
たぶん。「Web がドキュメントだけじゃなくなった」 と考えれば自然なんじゃないかと思う。
つまり、いままで HTTP の「レスポンスボディ」の中で 「ドキュメント」形式で表現されていた「リソース」だけじゃなくて、
もっと別の形の「何か」を Web は扱えるようになったと 考えるのはどうだろう。
というか、そもそも HTTP ではできなかったことを、 出来るようにしてしまったんだから、 そこから得られる結果が、 今までと全く変わってしまうのは、 当然だと思う。
その、「何か」を自分は「ストリーム」と 捉えたら面白そうだと思ってる。
自分の模索過程 http://d.hatena.ne.jp/Jxck/20111223/1324659260 https://gist.github.com/Jxck/stream.io
-
WebSocket によって扱えるデータはストリームという単位で抽象化可能と考える
-
ストリームは実装レベルでは Node.js の Stream という API を基準に考えているけど、たぶん汎用化可能。
-
ストリームは基本的に２種類
- Readable Stream
- Writable Stream
また、これを接続するために pipe という API を考える。
読み取り可能で、接続していればどんどんデータがやってくるストリーム。 データの発生がイベントとして pipe してるストリームに通知される。 水道の蛇口みたいなイメーじ。
ex) tail -f, twitter stream, stdin etc
データをどんどん書き込むことができるストリーム。 バケツのようなイメージ
ex) DB, File, stdout etc
WStrm と RStrem を繋ぐもの。 UNIX の pipe(|) と同じイメージ。
WStrm.pipe(RStrm);蛇口から水を組みたい人は、自分のバケツにパイプを繋ぐ。
tail -f を RStrm として抽象化。 DOM(つまり画面) を WStrm として抽象化。
２つを pipe で繋ぐ。
tail -f されたデータがサーバからどんどん push されていく。
// server
tailf.pipe(client);// client
tailf.pipe(client);twitter は twitter stream を WebSocket を用いた ReadableStream として公開する。 twitter stream を読みたい人はなんらかの WritableStream を用意して pipe しにいく。
pipe しにいくのはだれでも良い。 たとえば Google の bot も、そのデータを pull しにいくのではなく push してもらいにいくために ReadableStream としてリアルタイムなデータを収集できるのでは。
クライアント(RStrm) -> サーバ(WStrm/RStrm) -> クライアント(WStrm)
よくある双方向チャット。
t_wada さんが指摘する、時間を超えて合意を形成できる設計指針であるところの 「アーキテクチャスタイル」は WebSocket などを用いて実装するリアルタイムな Web には、今のところ存在しない。 まずは best practice/bad know how などを始めに自然発生的に少しづつ出てくるだろうという t_wada さんの考えには同意。
ざっとこんな感じ。正直まだ固まってない。