webAPI

APIとは

• アプリケーションプログラムインターフェイス。アプリとシステムの境界を指す。
• 特定のOSやフレームワーク上で動くアプリは、OSやフレームワークの提供する機能を利用して動く。OSやフレームワークはAPIと呼べる。

WebAPIとは

• もっとも原始的なWebAPIはHTTPプロトコル。
• Webサービスを利用するアプリがあるとすると、webサービスとアプリのやりとりはHTTPで行う。

WebAPIの歴史

• 初期のウェブページは人間が見るための文書が中心だった。
• このweb上の文書をデータとして処理しようとし始める
• HTML文章をデータとして処理するのに２つの問題点がある
  1. 緩いフォーマットであり、文法的におかしいHTMLでもそのまま流布する。
  2. レイアウトや文字装飾のデザインなどのデザイン情報も記述している。-> 不要なノイズである。
• 上記の事から、ノイズを除去して必要な部分を抜き出す「スクレイピング」が始まる。
• スクレイピングの問題点
  1. 正規表現などを使うため、コードが複雑
  2. HTMLの構造やタグの使い方が各ページによって異なるため特定のwebページにしか使えない。
• セマンティックweb
  • Web上の文章を人間のためのものから、プログラムでも扱えるデータにしようという流れ。
  • XMLやCSSもその流れによってできたもの。

XMLとは

• メタフォーマットと呼べる、様々なフォーマットを作成可能なアークアップ言語。
• XMLが決める規則はタグや属性などの形式。自由に決めることができる。

  を段落だと規則を決めるのは上位規格。

  • 整形式のXML　-> データ生成側と解釈側での合意のないXML。
  • 妥当なXML -> 上位規格でタグの意味を込めたXML。<p>はparagraphなど。
  • 妥当なXMLをXMLのスキーマと呼ぶ。構造を決めたXMLのこと。
  • webAPIではスキーマを使うことが妥当だが、新規のスキーマが乱立することを制御するべきだという流れがあり、その中で標準隣りつつあるのがAtom。

Atomについて

• IETF(インターネット技術を標準化する任意団体)による標準規格の、webサイト更新情報配信のためのフィード用フォーマット。
• 独自規格のRSSを置き換える目的で作られる
• メタフォーマットでもあるため、2つの規格を持つ
  1. フィードを目的とした規格。データフォーマット。
  2. Web上の文書更新を目的とした規格。フォーマットに従ったAtomデータをHTTPに載せて、更新データを一種の更新命令のように扱う規格。

JSON

• WebAPIのデータフォーマットで、Atomと並び重要なもの。
• JSONデータを外部に送信する場合は、内部オブジェクトをJSON文字列に変換。-> JSON.stringfy();
  • 受信した場合は、JSON文字列をオブジェクトに変換。 -> JSON.parse();

Web API規約

• 通信プロトコルとデータフォーマット
  • SOAPベース　-> XML
    • SOAPとはXMLで命令を記述するRPC。HTTP上にXMLで記述した命令を流しRPCを実現する。RPCとは、リモートプロシジャコール。ネットワーク越しの関数呼び出し。
  • RESTベース -> Atom JSON
    • HTTP上に流すのはドキュメントやリソースなどを更新するための更新情報のデータ。

WebAPIの形態

1. スクレイピング・・・非公式な手段
2. HTTP API・・・リクエストURLやレスポンスのデータ形式を定義。APIの歴史の始まり。
3. 言語API・・・関数やクラスライブラリを定義。HTTPの詳細を関数呼び出しやクラスの中に隠蔽する。
4. ウィジェットAPI・・・HTMLのコード片。HTML内に記述するだけで使用できる。ウィジェットの裏側に言語APIが隠蔽されている。

ここまでの流れ

RESTfulAPI

1. 非SOAPのAPIを総称してRestfulAPIと呼ぶ
2. 厳密にはそれは良くなく、RPC派とREST派と呼ぶ方がまだいい
3. RESTの考え方は、主軸をリソース（ドキュメント）と考え、許される操作はリソースの更新のみ。この制約がwebのスケーラビリティを支えているという考え方がREST論の骨子。
4. SOAPとRESTを比較するとURLの命名スタイルが異なり、動詞的（命令的）ならばSOAP,名詞的（ドキュメント的）ならばREST。

APIキー

• WebAPI利用のために発行されるキー。利用時に提出を義務付ける。
• リクエスト時のクエリパラメータでAPIキーを渡し、サーバー側がチェックする。
• 利用制限などが目的である。
• クライアントサイドではAPIキーをJSコード内に記述するので利用者がブラウザで簡単に読み取れる。
• そのため、秘密にしたい場合はWebAPI呼び出しは使えない。

ユーザー認証の仕組み

• セッション管理 HTTPリクエストがどの利用者からのリクエストか判別する仕組み
  1. HTTPは１リクエストに対し、１レスポンス。前後のリクエストを結び付けないため、管理する必要がある。
  2. 同じ利用者からのリクエストに対してリクエストを区別するマークを付ける。マークはクッキー、またはクエリパラメータ。
  3. そのマークを元にサーバー側で利用者を識別。
  4. Webサーバー側で利用者ごとに保持する状態をセッションといい、セッションに利用者情報を格納することでレスポンスを返す。

クッキーとは

• Cookieという名のHTTPリクエストヘッダ。
• Webブラウザがクッキーヘッダの値をローカルで記憶し、同じサーバーへリクエスト時は記憶しているクッキー値をリクエストに載せる。
• 異なるwebブラウザでは利用できない
• 機密情報防御のために、セッションIDが存在
  • Webアプリ上のセッション情報を引くためのキー
  • 乱数をもとに生成
  • ログアウト時や、一定時間利用なしだとIDをクリアする。->セッションタイムアウト値。
• セッションクッキー
  • Webブラウザの起動状態を意味する。
  • 有効期限なしだと、webブラウザが終了するとともに、クッキーは無効になる
  • 有効期限があると、ローカルディスクに残る

ユーザー認証の流れ

1. ログイン画面でユーザーIDとPWを入力
2. ユーザー情報を受け取ったwebアプリは内部のDBでPWを認証。成功すると、ログイン状態を管理するセッションを生成しセッションIDをクッキー値として返す
3. 以後クッキーの有効期限の間ログイン状態を保持
   • クッキーは発行元のwebアプリに対してのみ送信される規則があり、別のwebサーバーには送信されない。

WebAPIとユーザー認証

利用場面には3つの役割がある

1. Web APIの提供サーバ：サービス・プロバイダ
2. Web API利用アプリ：サードパーティアプリ
3. 利用者：ユーザー

認証と認可

1. 認証：身元を判断するために個人やプロセスが提示する資格情報の検証
2. 認可：何かしらの権限を個人にあたえること。利用者が何をするのかを決める

OAuth

1. 認可伝達プロトコル。もしくは権限委譲プロトコル。
2. サービスプロバイダ上の利用者の権限をサードパーティアプリに委譲するために使用。
3. アクセストークンの取得。時限付き秘密情報代替。

クライアントサイドJSからWebAPIを呼ぶ流れ

1. クライアントサイドが権限委譲を求めるリクエスト（サードパーティアプリがサービス・プロバイダに予め登録したアプリID）をサービス・プロバイダに投げる
2. ログイン済みであれば、権限委譲の確認画面を返す
3. 権限委譲許可をPOSTする
4. アクセストークンを発行し、サードパーティアプリにリダイレクト
5. クロスドメイン通信でWebAPIを呼ぶ