//tips
//webapi確認
引き続きwebapiの仕組みを確認していく。
前回apiでできることがhttpのgetやputなどのシンプルな機能に集約されることがわかった。
ただ、シンプルな機能をそのまま使用してしまうと不都合な場合も生じるため、絞り込みのパラメータを付加して対応する。基本的には?マークの後に続く文言が制約条件となる。
…v1/peaple-serch?first-name=Clair //Clairに該当する名前の検索
…v1/users?q=Ken //googleの場合、Kenという単語の全文検索、インスタの場合、Kenという名前の全文検索
などのように表現される。
Apiの設計において、特殊なものとして、ログインを行う際の認証のapiがある。
この認証の際にはOAuthという標準仕様をベースにするのが一般的で、第三者に公開されるAPIの認可を行うために用いられる。
例えば、ユーザー登録機能を持つFacebookのapiを利用して異なるサービスAを提供している場合、サービスAはfacebook経由でユーザー情報を利用したい。その場合に、ユーザーに対してfacebook登録情報をサービスAに渡していいかの許可を取る仕組みがOAuthである。
この際のやりとりは下記となる
1.サービスAの利用許可をユーザーからfacebookに出す
2.facebookはアクセス許可トークンをユーザーに発行
3.ユーザーはそのトークンをサービスAに渡す
4.サービスAはトークンを持ってfacebookに情報を依頼
5.facebookはサービスAに情報提供
また、Facebookなどを利用せず、自社のid,passで管理したい場合でもOAuthは使用できる。
アクセス許可トークンを入手する際のクライアントのリクエストは下記のようになり、
POST /v1/oauth2/token HTTP/1.1
Host:…
Authorization:Basic Base64変換code
Cotent-Type:application/x-www-form-unlencoded
grant_type=password&username=aaa&password=abcd&scope=api
サーバーのレスポンスとして、
HTTP/1.1 200OK
Content-Type:applocation/json
Cache-Control:no-store
Pragma:no-cache
{
“access_token”:”……..”,
“token_type”:”bearer”//OAuth2.0用のトークン形式,
“expires_in”:111111, //有効期限を迎えるまでの秒数
“refresh_token”:”……..”,
}
有効期限を超過してしまった場合にはリフレッシュトークンを使用して、
アクセストークンを再度要求することができる。
エンドポイントの末端を今まで見てきたが/usersの前に当たるuriも重要でそちらも決める必要がある。
api.twitter.com/1.1
のように基本的にはホスト名にapi.~~.comと記載し、apiであることを明示しているケースが採用されることが多い。
また、HATEOASという次のステップもあり、APIでのサーバーからのリスポンスデータの中に、次に行う行動、取得するデータなどのuriをリンクとして含めることで、紐づる式にたどり欲しい情報を取得するようにする方法もとられる。
{
“friends”:[
{
“name”:”Sam”,
“link”:{
”uri”:”https://api.example.com/v1/users/1234”,
”rel”:”user/detail” //そのデータと現在のデータの関係性を表す
…
このように、トップページを知ってさえいればそのページのボタンを押すことで、詳細の機能を辿って使用することができるのと同じことができる。
