質問ありますか?

RESTful なシステムが増えてきた 今後ますますデータが重要に Web API の可能性は広がる データを Web に解き放て Web アプリと Web サービスを分けて考えない

認証まわり まだこなれてない エラーの話 torum さんごめんなさい atom entry + hError?

表面的な違い 仕様の数 大ベンダの思惑 本質的な違い 統一インターフェース vs 個別インターフェース 複雑な MEP (Message Exchange Pattern) が必要かどうか

uddi public directory 終了 2005/12 変な REST 解説も多数 スルー力重要 REST/WS-* 使いわけ論 2006/02 良い API もたくさん Lucene とか APP まだ RFC にならない もうすこし

インタビュー at infoQ Tim Bray DHH

blog で対話形式がはやってます REST Dialogues by Duncan Cragg 9個の予定(現状二つ) The S stands for Simple by Pete Lacey ほとんど訳したんだけど最後の一文が訳せず挫折中orz

REST 本 来年5月? 今日話したような内容をより包括的に SOA への対抗イデオロギーとしての ROA

おわり

残念ながら決定的な手法は知らない 経験+センスがものを言う世界 「デファクト」重要 「真似」重要 センスの良い API を真似しよう GData, Hatena APIs

2 そのリソースに適した表現は何か? XHTML/microformats image/*, application/* 素 atom entry 拡張タグつき atom entry opensearch JSON, JSONP 独自マークアップ とりあえず XML-RPC はもうやめよう 無理して XML を使うのはやめる

1 リソースとその URI を基準に resource oriented 自分の Web サイトから提供したいリソースは何か? HTML/Atom からリンクしてうれしくないか? a/@href, img/@src, script/@src, link/@href

リンク可能なもの == REST 的に正しいリソース

件数取得の敗因(推測) 初めにメソッドコール的に考えた? フォーマットで悩んでしまった 画像取得の勝因(推測) img 要素からの利用(リンク)が念頭に?

キャッシュを有効利用 レスポンスコードを正しく利用 HTML から img/@src でリンク可能! Web アプリと Web サービスを分けて考えていない 細かいツッコミ 302 は Found じゃないの? (RFC2616) Moved Temporarily は RFC 2068 Expires を指定した方がいいかも

GET /users/normal/00036.png Host: b.hatena.ne.jp If-Modified-Since: Fri, 07 Jul 2006 08:54:03 GMT If-None-Match: "d7a218-1f9-f35b8700" HTTP/1.1 304 Not Modified Content-Type: image/png Etag: "d7a218-1f9-f35b8700"

HTTP/1.1 302 Moved Temporarily Location: http://b.hatena.ne.jp/images/users/normal/00036.pngGET /users/normal/00036.png Host: b.hatena.ne.jpHTTP/1.1 200 OK Content-Type: image/png Etag: "d7a218-1f9-f35b8700" binary data

リクエスト(ブックマーク数リソース) GET /entry/image/http://d.hatena.ne.jp HTTP/1.1 Host: b.hatena.ne.jp レスポンス HTTP/1.1 200 OK Content-Type: image/png binary data

HTTP/1.1 201 Created Content-Type: application/json Location: http://b.hatena.ne.jp/atom/exist/1234567890abcdefg { "http://d.hatena.ne.jp/naoya/20051212": 5, "http://yohei-y.blogspot.com" : 4 }

HTTP/1.1 201 Created Content-Type: application/atom+xml Location: http://b.hatena.ne.jp/atom/exist/1234567890abcdefg <feed xmlns="http://www.w3.org/2005/Atom"> <title>はてなブックマーク検索結果</title> </feed>

POST /atom/exist HTTP/1.1 Host: b.hatena.ne.jp Content-Type: application/xml <uri-list> <uri>http://d.hatena.ne.jp/naoya/20051212</uri> <uri>http://yohei-y.blogspot.com</uri> </uri-list>POST /atom/exist HTTP/1.1 Host: b.hatena.ne.jp Content-Type: application/x-www-form-urlencoded u…

query document を POST 201 レスポンスと Location ヘッダ

パラメータを複数渡さなければならない URI を50件指定可能 GET では書けない 複数パラメータを POST で渡せる XML-RPC

HTTP/1.1 200 OK Content-Type: text/xml Content-Encoding: gzip <methodResponse> <params> <param> <value> <struct> <member> <name>http://www.hatena.ne.jp/</name> <value><int>157</int></value> </member> <member> <name>http://b.hatena.ne.jp/</name> <value><int>1…</int></value></member></struct></value></param></params></methodresponse>

POST /xmlrpc HTTP/1.1 Host: b.hatena.ne.jp Content-Type: text/xml <methodCall> <methodName>bookmark.getCount</methodName> <params> <param> <value><string>http://d.hatena.ne.jp/</string></value> </param> <param> <value><string>http://b.hatena.ne.jp/</string></value> </param> <param> <value><string>ht…</string></value></param></params></methodcall>

悪い例と良い例 ・ はてなブックマーク件数取得 API http://d.hatena.ne.jp/keyword/%A4%CF%A4%C6%A4%CA%A5%D6%A5%C3%A5%AF%A5%DE%A1%BC%A5%AF%B7%EF%BF%F4%BC%E8%C6%C0API 懿｢ｫ ブックマーク数を画像で取得する API http://b.hatena.ne.jp/help/count#count

API? プログラムから(も)アクセス可能なリソース リソース表現はさまざま XHTML microformats image/*, application/* Atom JSON, JSONP

変えないのが重要 変えにくくする工夫 tkawa さんの map.resources 解説に期待

URI はクライアントに不透明 クライアントが URI をいじったり推測するしかないのはダメ(密結合) リンクをたどる Form から query を投げる URI template opensearch の {searchTerms} query params 以外をテンプレート化 http://www.ietf.org/internet-draf…

実装に依存しない *.pl とか リソースは名詞 URI に action (get/set など)は入れない セッションIDも入れない なるべくイマドキのフレームワークを使う Web アプリとWeb API で URI を分けない /xmlrpc とかはよくない