19章 Web APIの基礎
Web APIとWebサービス
- p422 APIとはApplication Programming Interfaceの略
Web APIの歴史
セマンティックWeb
- p424 簡単にデータを取り出せるようにするセマンティックWebという流れが現れ、XMLやCSSなどが誕生する。
- 提唱者はWebの創始者であるティム・バーナーズ=リー
XML
SOAP
REST
Web APIの構成
Web APIの形態
Web APIの利用
- Web APIは、サーバ上、Webブラウザ、ネイティブアプリのいずれから呼び出されるかで分類される
- JavaScriptから利用する上での制限には、クロスオリジン制限と、Web API呼び出しの通信方法を秘密にできないため、秘密にしたいロジックが実装できないことがある
RESTful API
- p429 SOAP以外のWeb APIを総称してREST APIもしくはRESTful API(REST風API)と呼ぶことが多い
- Representational State Transferの略語
- HTTPの仕様策定者の一人Roy Fielding氏が論文で使った造語
- RESTは特定の技術を指す用語ではなく、Webを特徴付ける分散システムのパターンを指す用語として使われた。このパターンにより、Webがスケールする理由とした
- RESTでは分散システム上の対象をリソースと呼ぶ
- リソースはURIという名前空間でアクセスされると、ある特定の形態で実体化される
- Webブラウザでアドレスを指定してアクセスすると、HTMLなどを取得し、それを表示するような流れ
- p430 リソースはHTTPのメソッドであるGET,POST,PUT,DELETEで操作する
- RESTではリモート操作をリソースの更新のみ(作成、削除も更新に含める)に限定する
- REST以前は、様々な操作が呼べるRPCを前提としたどのように操作するかが主軸
- SOAPとRESTの実務上の違いは、URLの命名スタイルの違い
- SOAPではURLは操作と対応付くので、動詞的な名前がつき、これとオブジェクトの名詞のセットになる
- RESTはURLはリソースと対応付くので、名詞的になる。動詞は現れない。動詞はGETやPUTなどのメソッドで表している。この命名方法がRESTfulの特徴で、分類手段としても妥当性がある
- SOAPベースのもの以外は、大勢を占める複雑なSOAP以外のものということで、実際には命名規約に従っていなくてもRESTfulを名乗ることが多い
ユーザ認証と認可
Web アプリのセッション管理
- Webアプリのユーザ認証はセッション管理による
- ユーザを判別し、Cookieや特別なクエリパラメータで記しずけをする。その記しとセッションを結びつけて状態管理をする
- p432 クッキーとセッション管理
- クッキーの有効期限
セッション管理とユーザ認証
Web APIと権限
- p433 書籍では、Web APIの提供サーバをサービスプロバイダ(SP)、Web APIの利用アプリをサードパーティアプリ、Webブラウザを操作している利用者をユーザと呼ぶ
- p434 SPは、GoogleやFacebookなどの大規模アカウントを保持しているサービスを想定
- サードパーティアプリはそれらのSPが提供するWeb APIを利用するWebアプリ
- サーバサイドからWeb APIを呼ぶ方がクロスオリジン制約などに悩まされないので実装しやすい
- ユーザからのWeb API呼び出しをサーバが中継する
- 中継するためボトルネックになる可能性がある一方で、同じWeb APIの呼び出し結果をキャッシュしたり呼び出しを集約できることで高速にできることもある
- Web APIへのアクセスは、ユーザの権限で行いたいが、Cookieが転送されることはないのでこれはできない
- OAuthでは、ユーザにSPで認証して、サードパーティアプリに権限を委譲することでセキュリティを保っている
クライアントサイドのWeb API呼び出しと権限
- p435 利用者がSPにログイン済みであれば、WebブラウザからSPへのリクエストはログイン済みのものになるが、この状態だと文章を削除するなどのWeb APIがすぐに実行できてしまうため、攻撃に利用されてしまう。これをCSRF(Cross-Site Request Forgeries)攻撃という
- SPにログインしているかどうかではなく、ちゃんとユーザがWeb APIの呼び出しに許可を与えるべき。これをやるのがOAuth 2.0
認証と認可
OAuth
- OAuthの詳細は http://oauth.net にて
- OAuthは認可伝達プロトコル
- OAuthを使うと、SPにユーザが認証するために情報を、第三者のサードパーティアプリに知らせることなく、認可が行える
- OAuthはサーバサイドでの認可で、OAuth2.0はクライアントサイドJavaScriptでも使える
- OAuth2.0のサーバサイドフロー
- OAuth2.0のユーザエージェントフロー
- Implicit Grantと呼ばれるユーザフローが使える
- p438 サードパーティアプリとSPのやりとりはない
- ユーザは、サードパーティアプリサーバから、Web APIが必要なHTMLファイルを取得
- ユーザのブラウザから、必要に応じて、SPの認証、Web APIの認可を行い、アクセストークンをSPに生成させる
- SPサーバはアクセストークンを発行して、ユーザのブラウザににリダイレクトする。その際、アクセストークンをURIフラグメントに仕込む
- クライアントサイドJavaScriptでURIフラグメントをパースしてアクセストークンを取得
- これ以降は、クライアントサイドJavaScriptから、クロスドメイン通信でクエリパラメータにアクセストークンを含めてWeb APIを呼ぶ