posted at 13:27:04
posted at 09:58:30
posted at 08:14:03
@kis HTTP/1.1 で Upgrade: ヘッダで切り替えるようなプロトコルになってるですね。/ 一応 cf. The Web Socket protocol <http://bit.ly/7lJEJF > posted at 00:18:38 @kis ですね。そういうふうに環境が充実していくのは重要な要因になっていくでしょね。ただ、リソースのモデリングは、まだまだ人間が意思決定しないといけないところだと思うので、やっぱり概念的理解は軽視できなろうなぁ、とも。→ 冒頭へループ ^^; posted at 00:31:24
@kis ラップするのにうまくできなかったり、遠回りするような実現方法になってしまったりしていないですかね。Comet API みたいな使い方とか、Web Socket みたいなのが必要とされ歓迎されていたりする現状を見ると。 posted at 22:31:01 @kis URI で指示可能なリソースが相互接続されたハイパーテキスト空間。という元来のセマンティクスとはずいぶんとずれた作られ方のウェブアプリもしばしば見掛けるのも。プログラミング重視の作られ方とミスマッチが大きいのかな、という気もしてるかしらん。 posted at 22:34:38 @kis 実現方法によるので、見てみないと断定できないかな。少なくとも、操作のコマンド/結果を送受信する、という作り方だとすればウェブ的ではないと思う。URI の先にあるものはリソースであって、処理機能であるべきではないので。可能ということと、どうあるべきかということは違うし。 posted at 22:58:34 @kis HTTP メソッドの DELETE, POST, PUT などは統一インタフェースとして既定されたもので、正当なもので。要求ボディに要求メソッドと相容れない操作が書かれているとか、特定の URI が何らかのの操作を表現しているとかは不自然なことが多いと。 posted at 23:09:04 @kis 例えば。GET /hoge?method=delete とか。/delete?id=hoge とか。リソースは情報の塊とでもいうような存在で、それに対する操作が HTTP メソッドですよね。 posted at 23:12:04 @kis RPC 的な使い方は、ウェブ的ではないと思うです。Web Socket 的な、持続的ストリームを使った漸次的なステートレス通信をするのも。/ Comet のような、応答を遅延させることでサーバからのプッシュ型通知はやり取りされる内容による、かな。 posted at 23:20:54 @kis 動くけど abuse なのでないかしらん、という立場です。/ 大ウェブサービスはウェブとは違う世界を組み上げてる感じで。そして、HTTPボディを見て選別したりする、ウェブアプリファイアウォールが出てきて、更にスタックを積み上げる羽目になる、と ^^; posted at 23:29:08
@higayasuo @kis リストのだと、Nested Twitter Replies <http://bit.ly/201bpr> とか、pbtweet <http://bit.ly/pR8hZ> とかのグリモンスクリプトが、下方向に参照先を並べてくれますね posted at 22:00:23
RT @kis: ついったでのin-reply-toとかのメタ情報は、これから先 重要になっていくから、返答をRTで行うような場合に明確な理由付けをもって嫌われるようになる。in-reply-toついてないと不便でしょー <http://bit.ly/4tEVeW> posted at 16:47:09
@kis おまけに、誰も言ってないのに自分からネタ振りですよ! これ <http://twitter.com/uokumura/status/4995208568> の後に、これ <http://twitter.com/uokumura/status/4995264342>。 posted at 02:34:03
RT @kis: 匿名の逆は記名だよ。<http://twitter.com/kis/status/4678356802> posted at 18:15:24
|
last update 06/04 08:59
ツイート検索
Recent
Archives
Friends
Hashtags
Stats・Feed |