前回は、マルチスレッドによるユーザビリティの向上 Web Workers についてまとめた。ここでは、アプリとシステムの間の境界 通信規約であるWeb API について解説する。
１ Web APIとWebサービス
API（Application Programming Interface）とは、アプリケーションプログラム（以降アプリ）とシステムの間の境界を指す用語である。開発者から見ると、APIとは関数やクラスの仕様である。
Web APIが想定するシステム
Web APIが想定するシステムはWebサービスである。Webサービスとアプリ間のHTTPの呼び出し規約がWeb APIである。つまりリクエスト先のURLの定義、クエリパラメータ名、レスポンスのフォーマットの定義などである。
- WebサービスとWebアプリ：ここではHTTPのリクエストとレスポンスに形式的な規約（定義）があればWebサービス、なければWebアプリと呼び分ける
２ Web APIの歴史
スクレイピング
スクレイピングとは、文法的に壊れているかもしれないHTMLから不要なノイズを除去して必要な部分だけを抜き出す処理である。これはHTML文書をデータとして処理する際の2つの問題に対処するために生まれた。1つはHTMLが緩いフォーマットだという点、もう1つはHTMLが文書の内容だけでなくレイアウトや文字修飾などのデザインの情報も記述している点である。
- スクレイピングの問題点：複雑になりがちであること、特定のWebページにしか使えないこと、HTML更新によって動作しなくなる可能性があること
セマンティックWeb
セマンティックWebはWebの創始者、ティム・バーナーズ＝リーが主導したものである。Web上の文書を人間のためのものからプログラムでも扱えるデータにしようという動きの象徴である。
XML
XMLはメタフォーマットとでも呼ぶべきもので、XMLをベースに様々なフォーマットを構築可能である（拡張可能なマークアップ言語 XMLの基礎知識９項参照） 。XMLをベースに構築した上位規格をXMLアプリケーションと呼ぶ（ここでは直感に合わせるためにXML上位規格と呼ぶ）。
- XMLの規格：タグや属性などの形式（<p>など）。形式だけXMLに従ったもの（整形式）と上位規格として仕様を決めたもの（妥当）の2種類がある
- XMLのスキーマ：タグの意味や構造を決めた規則。スキーマを記述する代表的な言語にはDTD、XML Schema、RELAX NGなどがある
Atom
AtomはRSSを置き換える目的で始まった。RSSはWebサイトの更新情報の配信をするフィード用フォーマットの事実上の標準である。RSSは独自規格として始まったが、AtomはIETFによる標準規格である。AtomはAtom Syndication Format（rfc4287）とAtom Publishing Protocol（rfc5023）の2つの規格に分かれている。前者はフィードを主目的とした規格で、後者はWeb上の文書の更新を目的とした規格である（ブログなどの更新情報を配信するためのフィードが基本 AtomおよびCRUD操作を実現 Atom Publishing Protocol参照）。
JSON
JSONはXMLと並びWeb APIのデータフォーマットの2大巨頭である（JavaScriptの記法でデータを記述できる JSONおよび配列、JSON、日付、正規表現 JavaScriptのデータ処理参照）。
SOAP
SOAPは前身の独自規格のXML-RPCをベースにした標準規格である。SOAPはパラメータの記述にXMLを使う。端的に言えば、SOAPとはXMLで命令を記述するRPCである。RPC（remote procedure call：遠隔手続呼出）とはネットワーク越しの関数（手続き）呼び出しである。つまりHTTP上にXMLで記述した命令を流してRPCを実現するのがSOAPである。
REST
AtomはRESTの思想をベースにしていて、SOAPはアンチRPCといえる。SOAPはRPC的な思想でリモートの手続きを呼び出す。このためHTTPに載せるXMLは命令と見なせる。一方、RESTの思想でHTTPに流すのはデータである。つまり、Atomで記述した情報は更新データであり命令ではない。
簡単なまとめ
Web APIとはWebサービスの呼び出し規約である。現状のWeb APIの動向は、データフォーマットはXMLとJSONに収斂しつつある。また、通信プロトコルはSOAPベースとRESTベースの2つが両巨頭である。SOAPベースはXMLと密に関連し、RESTベースはXMLのAtomまたはJSONと関連する。
３ Web APIの構成
Web APIの形態
Web APIの形態の進化は、以下の4つにまとめられる。なおHTTP APIや言語APIは著書独自の用語である。
- スクレイピング：非公式な手段
- HTTP API：リクエストURLやレスポンスのデータ形式を定義
- 言語API：関数やクラスライブラリ（JavaScript API、JavaScriptライブラリ）を定義
- ウィジェットAPI：HTMLのコード片。例えばFacebook Social Plugin、Twitter @anywhere、Google Friend Connect（GFC）
Web APIの利用
Web APIをどこから呼ぶかの違いで次のように分類できる。
- サーバ（Webアプリ）から呼び出し
- Webブラウザから呼び出し
- ネイティブアプリから呼び出し（デスクトップやスマートフォン）
現時点でWeb APIの主流はサーバからの利用である。理由はクライアントサイドJavaScriptからWeb APIを呼び出す場合に次の2つの問題点があるからである。クロスオリジン制限とWeb API呼び出しの通信を秘密にできない（APIキーなど）。
RESTful API
REST APIもしくはRESTful API（REST風API）とは、非SOAPのWeb APIの総称である。REST（Representational State Transfer）とは特定の技術を指す用語ではなく、Webというアーキテクチャを分析する中でWebを特徴づける分散システムのパターンを指す用語として生まれた。RESTを特徴づけるのはリモート操作をリソースの更新だけに限定する見立てである（Webのアーキテクチャスタイル（設計思想） REST参照）。
- SOAP vs REST：実務上の大きな相違点はURLの命名スタイルに表れる。SOAPのURLは操作と対応づけられる（動詞的）。一方のRESTはURLがリソースに対応づけられる（名詞的）
APIキー
APIキーとは、一部のWebサービスにおいてWeb API利用のために発行されるキーである。Web API利用時にAPIキーの提出を義務づける。APIキーの主な役割は以下の2つである。
- 利用制限（API呼び出し回数など）
- （将来的には）課金
４ ユーザ認証と認可
Webアプリのセッション管理
誰でも読める文書を取得するWeb APIであればユーザ認証は不要である。しかし、文書を更新したりあるいはアクセス制限した文書を取得するWeb APIであればユーザ認証が必要になる。
- ユーザ認証の仕組み：セッション管理とはHTTPリクエストがどの利用者からのリクエストかを判別する仕組み。Webアプリサーバ側で利用者ごとに保持する状態をセッションと呼ぶ。セッションに利用者の情報を格納することで利用者に応じたレスポンスを返せる
- クッキーとセッション管理：クッキーの実体はCookieという名称のHTTPリクエストヘッダ。Webブラウザはサーバから受け取ったクッキー値を記憶し、同じサーバへのリクエスト時には記憶しているクッキー値をリクエストに載せる。セキュリティ保持のため、値自体には意味のないセッションIDをWebブラウザとWebアプリの間でクッキーとしてやりとりする
- クッキーの有効期限：指定するとWebブラウザ側のローカルディスクに残り、Webブラウザを再起動した後もクッキーが有効なままである。指定しないとWebブラウザのを終了するとクッキは無効になる
セッション管理とユーザ認証
クッキーとセッション管理を使いWebアプリでユーザ認証を行う一般的な流れは以下の通り。
- セッション管理されていない利用者がログインの必要なWebアプリにアクセスするとログイン画面を表示する
- 利用者はログインでユーザIDとパスワードを入力する
- ユーザIDとパスワードを受け取ったWebアプリは内部のデータベースやディレクトリなどでパスワード認証を行う
- 認証に成功するとログイン状態を管理するセッションを生成してセッションIDをクッキー値として返す
- これ以後クッキーの有効期限とセッションの有効期限の間、利用者はWebアプリ上でログイン状態になる
Web APIと権限
ここではWeb APIの提供サーバをサービスプロバイダ（SP）、Web SPIの利用アプリをサードパーティアプリ、Webブラウザを操作している利用者をユーザと呼ぶことにする。
- サーバサイドのWeb API呼び出しと権限：クロスオリジン制限といった問題がないため実装が比較的容易。理想的には利用者がサービスプロバイダ上に持つアカウントの権限でWeb APIを呼ぶべき。権限委譲プロトコルのOAuthによってサードパーティアプリが利用者権限でサービスプロバイダのWeb APIを呼べるようになる
- クライアントサイドのWeb API呼び出しと権限：リクエストには利用者のサービスプロバイダ上のログイン状態と関連したクッキーが載る
- CSRF（Cross-Site Request Forgeries）：勝手に文書削除できるといった攻撃。この脆弱性対策として、利用者がWeb APIの呼び出しに許可を与えられる仕組みが求められる
認証と認可
- 認証（authentication）：身元を判断するために個人やプロセスが提示する資格情報の検証。事実上ログイン処理のこと
- 認可（authorization）：何かを行う、またはある場所に存在するための権限を個人に与えること。ログイン後に利用者が何をできるかを決めること
OAuth
OAuthは認可伝達プロトコル（権限委譲プロトコル）である。つまり、サービスAで認可されたことをサービスBに伝達するためのプロトコル規格である。
- OAuth 2.0のサーバサイドフロー：フローの目的はアクセストークンの取得。アクセストークンはいわば次元付きの秘密情報代替。アクセストークン付きのWeb API呼び出しは、サービスプロバイダ上で利用者アカウントの権限で実行される
- OAuth 2.0のユーザエージェントフロー：フローの目的はアクセストークンの取得。サードパーティアプリ（サーバサイド）とサービスプロバイダのやりとりはない
最後に
Web APIとはWebサービスの呼び出し規約である。クライアントサイドJavaScriptからWeb APIを呼ぶにはクロスオリジン制限の問題がある。この回避の方式としてユーザ認証と認可を説明し、権限委譲プロトコルのOAuthについてまとめた。
次回は、サードパーティアプリとエコシステムを構築する Web APIの実例について解説する。
 |
