yohei-y:weblog: REST の勝利宣言と良い XML の見分け方
ITpro Challenge 行ってきました。 豪華なメンバーでどの講演もとても面白かったですね。 江島さんの講演は、Web 上でサービスをやるとはどういうことなのかについてとても示唆に富んだ話だったし、 鵜飼さんのハッカーのソフト工学の話は職場的にすげータイムリーだったし、 なおやさんの話は同時代を生きてきた、生きている者としてとても共感できる内容だったし、 戀塚さんはこれぞハッカーという感じのすごい人でした。 僕は LT の最後に話をさせてもらったわけですが、 ネタを二つ持っていって聴衆のみなさんに選んでもらうことにしました。 結果は REST が勝ったので、当初の予告どおり REST の話をすることに。 結局お蔵入りになった XML の話ですが、もったいなかったので懇親会でお話させてもらいました。 プレゼン中で引用した Web ページはこちらです。 檜山さんの記事 XML ボキャブ
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
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
