yohei-y:weblog: APP の標準化作業がほぼ終了
Tim Bray からアナウンスがあったとおり、 APP の標準化作業がほぼ終了しました。 RFC 番号が付くのはしばらく先だと思いますが、 現状の仕様を実装してもう問題ありません。 最後の draft-17 ベースの仕様が RFC になります。今後の修正は editorial なものだけのはずです。 この先、Web API を設計する人は、まず APP が利用できないか検討しましょう。 APP を採用すれば自然と REST スタイルを採用することになります。 これまで悩みがちだった Web API の設計が、かなり楽になると思います。 Web API を設計する人は、オレオレXMLを設計する前に、Atom/APP をベースにしたらどうなるか、 を考えて見ましょう。きっと Atom/APP は良い選択肢になってくれるはずです。 日本では AtomPP で定着しつつあった Atom Publ
yohei-y:weblog: HTTP ステータスコードを正しく使おう
先月、ぐるなび API がリリースされていました。 ぐるなびさんの持っている膨大なデータベースに Web API を通して気軽にア クセスできるようになったのは、非常に喜ばしいし、その英断に感謝したいと 思います。 しかし、Web API 仕様書、特にエラー仕様を見てちょっとがっかりしました。 もう少し上手にデザインすれば、もっとよかったのに…、という思いです。 一度出してしまった API はそう簡単に変えられないと思いますが、 参考までに僕だったらどうするか、を書いてみます。 この仕様の一番の問題はエラーコードです。 以下は 2-2 のエラー仕様に記述されているサンプルです。 <?xml version="1.0" encoding="UTF-8"?> <gnavi> <error> <code>602</code> </error> </gnavi> タグが三つ(gnavi, erro
yohei-y:weblog: 次の話
blogger が落ちてたんで遅くなりました。 http://subtech.g.hatena.ne.jp/miyagawa/20060509/1147161767 http://naoya.g.hatena.ne.jp/naoya/20060509/1147157679 この Hack が素晴らしい。で、見てておもったんだけど、ウェブのフロントエンドアプリケーション作りが得意な人は、そのフロントエンドアプリケーションから利用するバックエンドの API を規定して、API のエンドポイントを任意の URL に設定できるとかそういうものを作ったりとか、そういう時代が来る。 大体近いんだけど、ちょっとまとめ方が違ってる。 (中略) Amazon Web Services みたいな、「APIでデータとれるのでどうぞあなたのアプリでつかってください」っていうのが旧時代の Web API で、Ama
yohei-y:weblog: REST ってやっぱり難しいかも。
前のエントリでこんなことを書いたばかりだけれど、REST ってやっぱりどうよ、という気分になったので久々に blog を更新してみる。 ただただしさんのおれだったらフォト蔵APIをこうするを読んで、僕が del.icio.us に書いた感想は +1。ID == URI ですよね。Cool URI は名詞であるべき、というのは強調したい。「日本REST協会」入りたくないなー(笑)。みんな休んでそう というもの。たださんのエントリでは URI と書くべきところが ID になっててちょっと気になったり、「作法」は「アーキテクチャ」じゃなくて「アーキテクチャスタイル」だ、とか思ったのだけれど、でも本筋としては納得の内容だった。 しかし、たださんのエントリの、たかはしさんや mizzy さんのコメントを読んでうーんと唸ってしまった。 僕にはお二人の言いたいことがわかる。んで両方間違っていないと思う。
yohei-y:weblog: Hatena ID Auto-Discovery について
昨日は SIGMOD-J の大会に行った後にアルファギークなお二人と食事をしてきました。 大会ではやはり naoya さんの Web 2.0 についての話が一番面白かったです。 周りにいた人の反応も一緒でした。 ちなみに僕は naoya さんは初対面。 食事に途中参加の高林君とはちょうど4年ぶりだったことが今判明。オリンピックみたいだ:-)。 naoya さんは普段から blog やブックマークを見ているので、ぜんぜん初対面な気がしなかったんですが、 僕としては REST だの Folksonomy だの microformats だのといった単語をガンガン喋ったり聞いたりするのが新鮮かつエキサイティングでした。 やっぱり直接会って話すのは大切だと実感です。 以下本題です。僕は話題に出遅れてしまったんですが Hatena ID Auto-Discovery について。 naoya さんには
yohei-y:weblog: REST 入門(その5) 四つの動詞 -- GET, POST, PUT, DELETE
» REST 入門 目次 前回、URI で特定できるリソースに HTTP の GET という動詞を適用して、 ある時点・条件での状態の表現を転送するのが REST だという説明をしました。 URI (名詞)に適用できる動詞は GET だけではありません。 今回は GET 以外の三つの動詞を紹介します。 前提知識 ここでは実際に稼動している REST 実装の例としてはてなブックマーク AtomAPI を使います。 はてなブックマークそのものの説明はしませんので、あらかじめご了承ください。 はてなブックマークに登録したひとつのブックマークを考えてみてください。 このひとつのブックマークエントリが、対象のリソースになります。 たとえば REST 入門の目次をブックマークしたとします。 このブックマークの URI は http://b.hatena.ne.jp/atom/edit/175062 で
yohei-y:weblog: REST -> AtomPP -> blog -> Permalink -> RSS/Atom -> Remixing (Ajax/Microformats/Folksonomy)
REST -> AtomPP -> blog -> Permalink -> RSS/Atom -> Remixing (Ajax/Microformats/Folksonomy) 少し前の話だが、Blog Hackers Conference 2005 に行った。 miyagawa さんのキーノートも、naoya さんの講演も、キーワードは Web 2.0 (的なもの)だなという印象だった。 中でも特に気になったのはこのスライドで blog が missing piece を埋めた、という話だ。 こちらのコメントにも書いたのだけれど、 ここでいう blog というのはいわゆる weblog system/service だけを指すのではなくて、 blog 周辺の技術 (RSS, Atom, AtomPP, REST, Permalink) が方法論として、プラットフォームとなる、というの
yohei-y:weblog: 疎結合と XML
疎結合(loosely-coupled)って何でしょう? 僕自身、適当に疎結合という言葉を使ってしまいがちですが、 ちゃんとした説明なり定義なりが必用だと感じています(自分のために)。 いいかげんな定義で話をはじめると、 各人の方向性がずれまくって議論ができないですよね。 Web サービスしかり、 SOA しかり、REST しかり。 ということで今回は僕なりに疎結合ってこんなもの、 というのを考えてみます。 ものすごく一般化してしまうと、 疎結合というのは複数のコンポーネント間の結び付きが ゆるいことを指すんでしょうね。 たぶん、ここまでは誰でも同意してくれるはず。 ただこれだけでは議論ができなくて、 このコンポーネントに何をもってくるかを決めて、 はじめて具体的な話ができます。 僕がここで話したいのは Web サービスの文脈での「疎結合」ですから、 コンポーネントは Web サービスにな
yohei-y:weblog: REST 入門(その7) ハイパーメディアの可能性
» REST 入門 目次 前回は REST で受け渡しされるリソース同士が、 URI を使ったハイパーリンクで相互に結び付けられることによってハイパーメディアを実現し、 その機能拡張には XML 名前空間などが利用できることを説明しました。 今回はより応用的なハイパーメディアと REST の関係を見ていきたいと思います。 例によってはてなブックマークを使って説明します。 リソースの URI はひとつではない 現状のはてなブックマークでは、 ひとつのブックマークエントリ(リソース)の URI は僕が知る限り以下の三つがあります。 ブックマーク一覧 http://b.hatena.ne.jp/yohei/20050429#187800 人間用 Edit URI http://b.hatena.ne.jp/yohei/edit?eid=187800 Atom API 用 Edit URI htt
yohei-y:weblog: REST 入門
日本語の REST のリソース集を以前作ったのだが、 日本語では一般人向けの解説がない。 sheepman 氏の REST のページはすばらしいんだけど、多少わかっている人向けだ。 市山氏のプレゼン資料は RoyF の論文を詳しく解説していてよいのだけれど、いかんせんアカデミックすぎる。 技術的な要素も抑えつつ、入門者にもわかりやすい解説はないものかと探していたのだが、みつからない。 英語の文書を訳すことも考えたんだけど、あまりよいものが見つからない。 で、結局自分で書くことにした。 最初はひとつのポストで済ませるつもりだったんだけど、書き始めたら長くなってしまったので、複数のポストに分けることにした。 えらそうなことを書いたが、内容は「ないよりマシ」といったレベルだろう。 前書きが長くなったけど(ここから始まりです。ですます調なのは入門記事だから)、 この記事(から始まる一連のポスト)は
yohei-y:weblog: del.icio.us ボタンも付けてみた
はてなブックマークボタンを付けたのだが、僕が常用している SBS は del.icio.us なので、そっちのボタンも付けようとしたものの、ブックマークに追加する方はうまい方法を見つけられなかった。del.icio.us api だとうまくいかないし、bookmarklet はユーザ名が入ってしまっている。仕方がないので、「このエントリーを含むブックマーク」の方だけ実装した。ミソは javascript の MD5 ライブラリ。del.icio.us の各ブックマークリソースの URL はオリジナル URL の MD5 ハッシュを含んでいるので、下記のような javascript で実現できる。 <script type="text/javascript"> var hash = hex_md5("<$BlogItemPermalinkUrl$>"); var url = "http://
yohei-y:weblog: REST は XML の王道
最近の僕の日記のエントリを見ていただければわかると思いますが、もう完全に REST に傾倒しています。自分はなんでこんなに REST に惹かれるのだろうと考えてみたんですが、なんとなく答えがわかりました。REST には XML Guy の王道(XML の王道)が具現化されているのです。 いったん話を 1998年に戻しましょう。1998年、僕たちには華々しい未来がありました。それまでの大文字の HTML が XML によってプログラマブルに拡張される。名前空間やリンク機構を生かしてそれまでの Web が大幅に進化する。Jon Bosak の XML, Java, and the future of the Web や村田さんの「XML入門」に語られているような未来です(村田さんたちが訳したJon Bosak の記事の日本語版が見つけられなかった…)。 しかし世の中はその後さまざまな方向に迷走
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
