yohei-y:weblog: 『Webを支える技術 ── HTTP、URI、HTML、そしてREST』という本を書きました
このブログ、1年近くご無沙汰していました。その間なにをやっていたかというと、実はずっと本を書いていました。『Webを支える技術 ── HTTP、URI、HTML、そしてREST』というなんとも挑戦的な題名の本です。技術評論社さんのWEB+DB PRESS Plusシリーズの11冊目で、来月発売される予定です。 Webを支える技術 ── HTTP、URI、HTML、そしてREST山本 陽平技術評論社 2010-04-08 この本は、WEB+DB PRESSで連載していた「RESTレシピ」という連載がベースになっています。実は連載が1年経ったくらいから、技評さんからは書籍化のオファーをもらっていました。ただ、その時点では書いた分量も少ないし、そもそも自分に雑誌記事とは比べ物にならないくらい分量のある本が書けるとは思っていなかったので、書籍ではなく連載継続という形でトータル2年間連載をしました。
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: S はシンプルの S
This entry is a Japanese transration of Pete Lacey's "The S stands for Simple". Burton グループのアプリケーションプラットフォームサービスグループでは、 REST派とSOAP派の間でずっと継続中の議論がある。 その大部分は外部での議論によく似ている。 最近のやりとりの一つ、 SOAP と Web サービスフレームワークの複雑さの議論で、 SOAP 側は「WS-* の前は、SOAP は実際にシンプルだった。S はシンプルの略だ」といった。 さあ歴史を学ぼう。 2000年、悩める開発者が問題をかかえている。 開発者: うちの上司が先週末ゴルフをやってきて、 いわゆる SOAP なエンタープライズをやる必用があるんです。 でも私は SOAP が何なのか知りません。 教えてもください、 SOAP の人。 SOAP
yohei-y:weblog: REST ってやっぱり難しいかも。
前のエントリでこんなことを書いたばかりだけれど、REST ってやっぱりどうよ、という気分になったので久々に blog を更新してみる。 ただただしさんのおれだったらフォト蔵APIをこうするを読んで、僕が del.icio.us に書いた感想は +1。ID == URI ですよね。Cool URI は名詞であるべき、というのは強調したい。「日本REST協会」入りたくないなー(笑)。みんな休んでそう というもの。たださんのエントリでは URI と書くべきところが ID になっててちょっと気になったり、「作法」は「アーキテクチャ」じゃなくて「アーキテクチャスタイル」だ、とか思ったのだけれど、でも本筋としては納得の内容だった。 しかし、たださんのエントリの、たかはしさんや mizzy さんのコメントを読んでうーんと唸ってしまった。 僕にはお二人の言いたいことがわかる。んで両方間違っていないと思う。
yohei-y:weblog: Web らしく URI で連携する方向
前のエントリで触れた ID だけのディスカバリの問題点ですが、 他にもこんなのもあります。 僕が自分のブログにはてな ID を埋め込んだとして期待するのは、 ブログを訪れた人が自分のブックマークやアンテナを見に来てくれたり、投げ銭してくれたりすることです。 でも僕がはてなで何を使っているかは僕にしかわかりません。 僕の場合はてブとはてアは使ってるけど、 はてダは更新を止めちゃった、はてフは知らん、という状況です。 もしかしたらアサマシは嫌いだから投げ銭してほしくない、という人もいるかもしれない。 これって「はてなID」の埋め込みだけでは実現できません。 自分ははてなのこのサービスを使っているよ、という主張をできないからです。 ではどうするか。 自分ははてなのこのサービスを使っているから見に行ってね、という宣言をしたらどうでしょう。 head 内で宣言するんだったらこんな感じ。 <link
yohei-y:weblog: はてなブックマークのタグ編集に Atom PP を用いる件について
楽しそうなので、考えてみることにする なにはともあれはリソースのことを考えよう。 タグをリソースとするならまずはそれに URI を割り当てなければならない。 僕(yohei) の "atompp" というタグの URI は以下のような形式とする。 http://b.hatena.ne.jp/atom/yohei/tag/atompp 次に考えるのはタグリソースの 表現に何を使うか。 構造を持った情報なので XML になるのはすんなり確定。 問題はその形式。候補は以下のとおり。 最新 AtomPP のメンバー要素(member) 長所: 軽い、簡単 短所: member/@href で参照する先の URL はどの XML 形式にする? あるいはタグ名のテキスト(plain/text)か? Atom の entry 要素(entry) 長所: 標準。使える子要素がいろいろ定義されている 短所:
yohei-y:weblog: REST の日本語リソース
日本で REST がぜんぜん盛り上がっていないようなので、日本語で読める REST のリソースをまとめてみた。 東大市山氏による Roy Fielding の論文紹介。技術的な要素を理解したいけど RoyF のドク論を読むのは厳しい人にはお勧め。 http://kumiki.c.u-tokyo.ac.jp/~ichiyama/projects/reports/pdmwa 元論文はこれのようだ Principled Design of the Modern Web Architecture http://www.ics.uci.edu/~taylor/documents/2002-REST-TOIT.pdf 同氏による REST 版ショッピングカートの実装例。こちらも参考になる。 http://kumiki.c.u-tokyo.ac.jp/~ichiyama/projects/reports
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
