はてなと rest api

©2005 株式会社はてな　本資料の一部または全部の無断複製・転載を禁じます

はてなと REST API

株式会社はてな伊藤直也

[email protected]


アジェンダ

はてなの取り組みはてなブックマークと AtomPP フレームワークと Web API AtomPP は銀の弾丸 ?


はてなの取り組み


はてな

知的生産ツール群を提供する代官山にあるベンチャー企業


はてなウェブサービス

フィードによるデータ再利用を促進 API の公開

はてなキーワードリンク API はてなブックマーク AtomAPI はてなフォトライフ AtomAPI


XML ウェブサービスAPI

It's developer friendly, user friendly, and is a web site as well as a "service" or "platform" (in the Web 2.0 sense) all at the same time. (Jeremy Zawodny http://jeremy.zawodny.com/blog/archives/002526.html)

サービス

ブックマーク、ダイアリー

etc.

hatena.ne.jp

RSS フィード、キーワードリ

ンクAPI 、 Atom

API

デベロッパー、Geeks

エンドユーザー

なぜ API を公開するの ?


なぜ Geek にイケてるのが重要なの ?

• はてなアンテナ、はてなダイアリー、はてなブックマーク

• Blog / RSS

• iPod / Google / Movable Type / Bloglines / Flickr / del.icio.us …

テクノロジー・ライフサイクル(http://www.goodpic.com/mt/archives/000227.html)

技術革新を伴うサービスは Geek & パワーユーザーが広める


データ重要

Web 2.0 (Tim O'Reilly) Data is the Next Intel Inside You control your own data

で、どうやって ? インポート / エクスポートフィードフィードで過去の物も遡れる API で保存、編集、削除、取得


はてなブックマークと AtomPP


はてなブックマーク

ソーシャルブックマークサービス


はてなブックマーク AtomAPI

AtomPP 0.3 REST

ブックマークの新規投稿 (POST) 投稿したブックマークの取得 (GET) ブックマークの編集 (PUT) ブックマークの削除 (DELETE)

WSSE 認証


新規ブックマークの投稿

PostURIへの XML文書 (entry)の POSTPOST /atom/post

<?xml version="1.0" encoding="utf-8"?><entry xmlns="http://purl.org/atom/ns#"> <title>Starwars Episode III</title> <link rel="related" href="http://www.starwars.com/" /> <summary type="text/plain">Darth Vader, Rise</summary></entry>


ブックマークの取得

EditURI への GET or FeedURI への GET

# requestGET /atom/edit/1234

# in response<?xml version="1.0" encoding="utf-8"><entry xmlns="http://purl.org/atom/ns#"> <title>Lorem Ipsum</title> <link rel="related" href="http://www.lipsum.com/" /> <link rel="alternate" href="http://b.hatena.ne.jp/sample/20050407#1234" /> <link rel="service.edit" href="http://b.hatena.ne.jp/atom/edit/1234" /> <author> <name>naoya</name> </author> <issued>2005-04-07T:18:36:00+9:00</issued> <id>tag:hatena.ne.jp,2005:bookmark-naoya-1234</id> <summary>Lorem Ipsum is simply dummy text of the printing</summary></entry>


ブックマークの編集

EditURI への PUTPUT /atom/edit/1234

<entry xmlns="http://purl.org/atom/ns#"> <title>Parrot</title> <summary>All the language belong to us.</summary></entry>


ブックマークの削除

EditURI への DELETEDELETE /atom/edit/1234

200 OK


一覧取得

FeedURI + クエリパラメーター = Atom フィード GET /atom/feed GET /atom/feed?tag=hatena GET /atom/feed?word=perl GET /atom/feed?date=20050701 GET /atom/feed?date=latest GET /atom/feed?of=50

それぞれの entry に EditURI link 要素でページング<link rel="prev" href="http://b.hatena.ne.jp/naoya/atomfeed?of=0" /> <link rel="next" href="http://b.hatena.ne.jp/naoya/atomfeed?of=40" />


XML::Atom で AtomPP

XML は一行も出てこない#/usr/local/bin/perluse strict;use XML::Atom::Entry;use XML::Atom::Client;

my $PostURI = 'http://b.hatena.ne.jp/atom/post';

my $entry = XML::Atom::Entry->new;$entry->title('Alpha Neet');$entry->content('Honestly, I think I'll be loser if I start to work.');...

my $api = XML::Atom::Client->new;$api->username('naoya');$api->password('foobarbaz);$api->createEntry($PostURI, $entry);


なんで AtomPPにしたの ?

モテそうだったから REST とかかっこいい系 ?

他の API との相互交換性ユーザーがはてなのためだけに開発しなければいけ

ない物、覚えなければいけないことが減るユーザーが既存のライブラリを使える

XML::Atom etc はてなのアプリケーションと REST の相性が良

さそうだったから


フレームワークとWeb API


はてなと Cool URI

Cool URI 重要モテそう

はてなと Cool URI /naoya/ /naoya/rss /naoya/add?url=http://www.motetakute.net/ /naoya/config /keyword/perl

REST を意識していたわけではないが、なんとなくいい感じの URI を意識してたら REST と相性がよさそうな感じに。


MVC フレームワークと URI

MVC フレームワークの Best Practice M … O/R マッパ V … テンプレートエンジン C … それぞれに特徴的なアーキテクチャ

Controller Cool URI を意識するなら URI to Class / method の

dispatch に規約を ! Convention over Configration


例 : Ruby on Rails

/items ItemsController.index

/items/list ItemsController.list

/items/create ItemsController.create


例 : はてなフレームワーク

/ Hatena2::Bookmark::EngineIndex->do +

Hatena2::Bookmark::PageMakerIndex->make

/atom EngineAtom + PageMakerAtom

/atom/post EngineAtomPost + PageMakerAtomPost

/add?mode=confirm EngineAddConfirm + PageMakerAddConfirm


URI に対応する規約があると

プログラマが URI に無知でも割と綺麗な URI のアプリケーションになる

「Model をリソースと見立て、その Controller を起動する URI を決める」という自然な考え方ができる。

URI を見ただけで変更箇所が分かる /atom/post は EngineAtomPost だね

結果、 REST に近づくため REST API との相性が良くなる


フレームワークと Web APIs

Catalyst Catalyst::Plugin::XMLRPC Catalyst::Plugin::AtomPP

Ruby on Rails ActionWebService

Web APIs を容易に扱えるように、そのアーキテクチャを抽象化することが重要になってくる

AtomPP や XML-RPC など標準化 (?) されてるものはフレームワークに搭載しやすい


AtomPP は銀の弾丸 ?


AtomPP は銀の弾丸ではない

REST / AtomPP の制約が邪魔なことも小さな API を作るとき

URI に対して被コメント数を返すとか。大げさ、無理矢理、どうしたらいいかわからない

エレメントに対応するデータが直感的でない summary がコメント ? title がタグ ?? 結局仕様書が必要ほんとにこれでいいの ? という疑問

サーバーサイドの実装がややめんどくさいやっぱりフレームワーク重要


del.icio.us / api

XML over HTTP Basic 認証 + 野良 XML

GET /api/posts/recent HTTP/1.0

<posts tag="" user="naomax"><post href="http://...html" description="XML-Atom 0.12" tag="xml atom perl" time="2005-06-08T05:50:02Z"/><post href="http://...html" description="Japan.internet.com" tag="podcasting" time="2005-06-08T05:49:07Z"/><post href="http://...html" description="blah blah" tag="system:unfiled" time="2005-02-11T19:33:21Z"/>...</posts>

シンプルで分かりやすいデータの項目が明快小さな API も気にせず実装できる Net::Delicious


まとめ

Web APIs を公開するのは意味がある REST 的なアプリケーションなら AtomPP

ただし、銀の弾丸ではないよ URI とフレームワークの規約重要 Web API を実装しやすくするフレームワークの

進化に期待モテたくて 2.0


ご清聴ありがとうございました。

はてなと rest api

Documents