//tips
//webapi確認
「Web api the good parts」と先のYouTubeを見ながら理解を深めていく。
Apiの基本は、あるuriにアクセスすることで、サーバ側の情報を書き換えたり、サーバ側に置かれた情報を取得できたりするシステムで、このシステムはプログラムを通して利用できる。
また、このuriにアクセスして得られる情報はjson形式であり、ブラウザに直接表示することができるhtmlではないため、取得した情報は各自で加工する必要がある。
このapiの公開では、見知らぬ第三者が利用することが前提となるため、仕様書を公開する必要があり、そのためswaggerが重宝されていることがわかった。
この公開にあたっての仕様書がルール(Restful)に則っていることも大事になっている。
このように書いているとなんだか難しい感じがするので、もっともシンプルな例を考える。
一番シンプルな形のapiは、ユーザーが自身の取得アプリまたはブラウザから、それらのサービス提供元のサーバー情報を直接操作することができるようにすること。
エンドユーザーがサーバーをいじるのを手助けするものといえる。
このシンプルな形が使われないのは、データがわかりづらいからとセキュリティ上非常に問題があるからで、それらの問題を解決して初めてまともなapiということができる。
具体的なApiの設計フローを確認する。
まずは、アプリの画面と遷移先を図表化し、そこから必要な機能項目を列挙していく。
項目を整理し、提供機能を決めるとそれが作成すべきapiとなる。
Apiを作成する第一ステップはエンドポイント(システムを利用するための入り口となるURI)を設定することで、apiを取り込む側の開発者が仕様書をいちいち確認しなくてもよいようにuriで用いられる単語は注意を払いわかりやすいものにする。
このuriに対してhttpのメソッドを実行してきたのが先日から行なっているapi実装となる。
uriというリソースへの案内役に対して、httpのget/postメソッドを実施することになる。
このuriは
http://api.example.com/v1/users
ような形になっている。v1の部分はapiのバージョンを表す部分で、usersまたはusers/:idの部分はユーザー集合と特定ユーザーを表している。
この集合と特定の個人に対して、HTTPメソッドで操作していく考え方は、apiの基本となっている。
一つのapi設計の例として、ベースとなるhttp://api.example.com/v1/usersに対して、httpメソッドを組み合わせると下記のような処理を行うことができる。
GET:ユーザー一覧取得
http://api.example.com/v1/users
POST:ユーザー新規登録
http://api.example.com/v1/users
GET:特定ユーザー情報取得
http://api.example.com/v1/users/:id
PUT:特定ユーザー情報更新
http://api.example.com/v1/users/:id
DELETE:特定ユーザー情報の削除
http://api.example.com/v1/users/:id
この延長線で考えると/users/:id/friendsとすると特定ユーザーの友達一覧であることが類推できる。
この一連の流れはデータ自体がサーバサイドのテーブル形式データに格納されていることを想像しながら追っていくとわかりやすい。
