前回で簡単な動機付けを行ったので、今回はもう少しAPIの詳細に入っていく。
APIの設計
現実に利用されているRESTなAPIというと色々あるけど、ひとまず一番実績のありそうなTwitterを参考にすることにする。というわけでここの資料を読む。なんか色々書いてあるけど、とりあえず現時点で知りたいのは1点だけ。
- そもそもURLはどういう風になっているのか？
APIにとって重要な点の一つはインタフェースが変わらないこと、変わるとしても以前のAPIがそのまま使用できる互換性を維持することなので、その辺Twitterがどうやってるのかを見たい。
で実際いくつかのAPIのURLを持ってきた。
- http://api.twitter.com/version/statuses/public_timeline.format
- http://api.twitter.com/1/users/show.format
- http://api.twitter.com/1/friendships/create/id.format
見ると、URLは基本的に以下の要素で構成されていることがわかる。
- ルートドメイン（http://api.twitter.com/のあたり）
- APIのバージョン番号（/1/のあたり）
- APIの種類（/statues/とか/users/のあたり）
- 実際のコマンド（/public_timelineとか/create/idのあたり）
- サーバーに要求しているレスポンスの種類（formatのあたり。実際に入るのはxmlとかrssとかの拡張子）
APIのバージョン番号を直接URLに埋め込んで互換性を維持している点が特徴と言えば特徴で、わりと合理的な感じ。ということでこの構成をそのまま拝借することにする。
想定するサービス
APIを作るにはそもそもどういうサービスを作るかを想定しなきゃならない。今回はサンプルなので、シンプルに以下のようなサービスを想定する。ブログのコメント欄のようなもの、といえばわかりやすいか。
- 匿名な利用者が発言を書きこめる。
- 書き込まれた発言は時系列順に誰でも閲覧することができる。
これだけ。
発言を送るためのAPI
サービスの細かな仕様は作りながら考えていくとして、ひとまず発言をサーバーへ送るためのAPIを設計する。URLは先ほどの構成を拝借して、以下のような形にする。ちなみに、見ればわかるけどサーバーはローカルで動いてるものを対象としている。
- http://localhost:8080/1/remark/send
このURLに対してPOSTすると、発言がサーバーサイドで蓄積される、ということ。
（続く）
0 件のコメント:
コメントを投稿