以下の内容はhttps://am1tanaka.hatenablog.com/entry/2015/02/13/235800より取得しました。

パーフェクトJavaScript勉強メモ(19)

JavaScript Web 書籍

前へ | 次へ

19章 Web APIの基礎

Web APIとWebサービス

Web APIが想定するシステム
  • Web APIは、HTTPでリクエストを送り、結果を受け取る規約のこと

Web APIの歴史

スクレイピング
  • Webページはもともと人間が読む文章を載せる場所だった
  • 文章をデータとして扱う新しいサービスの発案
  • データとして使う問題点
    • HTMLが緩い文法で、多少の間違いはサーバ上で修正して動作する
    • HTMLは文章だけではなく、レイアウトなどの情報も含む
  • 文法的に壊れている可能性があり、レイアウトなどの情報が散らばるHTMLの中から必要なデータを抜き出す方法をスクレイピングという
  • スクレイピングの問題点は、コーディングが難しく、また、特定のページにしか有効ではない。ページが更新されると使えなくなる可能性がある。
セマンティックWeb
  • p424 簡単にデータを取り出せるようにするセマンティックWebという流れが現れ、XMLやCSSなどが誕生する。
  • 提唱者はWebの創始者であるティム・バーナーズ＝リー
XML
Atom
  • RSSを置き換える目的で始まる
  • RSSは独自規格として始まったが、AtomはIETFによる標準規格
  • AtomはXMLベースであり、かつ、自身も拡張可能なメタフォーマット規約
  • Atomには、フィードを主目的としたAtom Syndication Format(rfc4287)と、Web上の文章の更新を目的としたAtom Publishing Protocol(rfc5023)の2つの規約に分かれる
JSON
SOAP
  • HTTPはRPC(リモートプロシージャルコール)と捉えることができる
  • RPCはネットワーク越しの関数呼び出しで、Web初期からこういう利用があった
  • p426 フォームの入力の文字を送信ボタンで送る処理は、ボタンの種類を関数、文字をデータとした関数呼び出しと見なせる
  • より汎用的なRPCを実現するためにパラメータを形式的に定義するのがSOAP
  • SOAPとRPC
    • SOAPは独自規格のXML-RPCを標準規格化したもの
    • SOAPは、命令を記述したXMLをHTTP上で送信してRPCを実現するもの。HTTPである必要はないが、ほとんどHTTPが利用されている
    • 2000年前後に広まり、一時期はSOAP=Webサービスという解釈が広まった
    • WSDLは、インターフェース定義の記述言語で、RPCの形式（パラメータと返り値）を記述する役割
    • UDDIはWSDLを発見するためにディレクトリの役割をする記述言語
REST
  • Atom Publishing ProtocolはRESTの思想を受けている、アンチRPC的なもの
  • SOAPはRPC的な思想であり、リモートの手続きを呼び出す
  • RESTは、リモートの取得や更新のためにドキュメントやリソースなどのデータを流し、命令に相当するものはHTTPのメソッド(GETヤPOSTなど)で示す
  • Atomで流すのは命令ではなく、更新データということ
簡単なまとめ

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を名乗ることが多い
APIキー
  • Web APIを利用する際にAPIキーと呼ばれるキーを発行するものがある。役目は以下のとおり
    • 利用制限(API呼び出し回数など)
    • (将来的な)課金
  • p431 利用制限は様々なWeb APIで行なわれている。課金は書籍の段階では存在しない(補足：Google Maps APIは有料版がある。ただし、APIキーで特定しているのかは調べていないので不明)
  • APIキーを秘密にするかは微妙
  • APIキーをJavaScriptから利用する場合、隠すことができない
  • ネイティブアプリでも同様なので、APIキーを隠す必要がある場合はサーバから呼び出す必要がある

ユーザ認証と認可

Web アプリのセッション管理
  • Webアプリのユーザ認証はセッション管理による
  • ユーザを判別し、Cookieや特別なクエリパラメータで記しずけをする。その記しとセッションを結びつけて状態管理をする
  • p432 クッキーとセッション管理
    • Webブラウザはサーバから受け取ったCookie値を記憶し、同じサーバへのリクエストに含める。これにより、サーバは同じブラウザの状態を維持できる
    • セッションはブラウザ単位なので、同じブラウザを他のユーザが使ってしまうと利用者の区別ができないので、そのまま利用し続けるとセキュリティが保てない
    • ログアウトしたらCookie値を消したり、Cookie値に有効期限を設けるなどすることで、リスクを減らしている
  • クッキーの有効期限
    • セッションクッキーという言葉があるが、これはWebアプリ側のセッションとは無関係で、Webブラウザの起動状態を意味する用語
    • 有効期限を設定しないCookieはブラウザを閉じると消える。このようなものをセッションクッキーという
    • 有効期限を設定したCookieはブラウザを動かしているローカルディスクに保存され、ブラウザを閉じても値は維持される。時間が過ぎればブラウザが起動中でも消える
セッション管理とユーザ認証
  • 未認証時は、IDとパスワード入力を促す
  • サーバにIDとパスワードが送られてきたら、ユーザDBなどでチェックを行い、正しい情報だったらログイン用のセッションを生成して、認証したことをセッションに記録させる
  • Cookieとセッションの有効期限の間、ユーザはログイン状態になる
  • Cookieは発行元のWebアプリにのみ送信し、それ以外のサーバには送らない
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
認証と認可
  • 認証とは、身元を判断するための資格情報の検証
  • 認可とは、何かを行う、またはある場所に存在するための権限を個人に与えること
  • p436 Webアプリの認証は、ログイン処理のこと。IDと対応するパスワードを知っていることで本人とみなす
  • SPが提供するWeb APIを使ってよいと、ユーザが、サードパーティアプリに許可を与えるのが認可
OAuth
  • OAuthの詳細は http://oauth.net にて
  • OAuthは認可伝達プロトコル
  • OAuthを使うと、SPにユーザが認証するために情報を、第三者のサードパーティアプリに知らせることなく、認可が行える
  • OAuthはサーバサイドでの認可で、OAuth2.0はクライアントサイドJavaScriptでも使える
  • OAuth2.0のサーバサイドフロー
    • p437 サードパーティアピりが、利用者の権限でSPのWeb APIにアクセスする
    • Web APIにアクセスするための時限付きのキーであるアクセストークンを取得する
    • 有効なアクセストークンが含まれるWeb API呼び出しには、ユーザの権限が設定されている
  • OAuth2.0のユーザエージェントフロー
    • Implicit Grantと呼ばれるユーザフローが使える
    • p438 サードパーティアプリとSPのやりとりはない
    • ユーザは、サードパーティアプリサーバから、Web APIが必要なHTMLファイルを取得
    • ユーザのブラウザから、必要に応じて、SPの認証、Web APIの認可を行い、アクセストークンをSPに生成させる
    • SPサーバはアクセストークンを発行して、ユーザのブラウザににリダイレクトする。その際、アクセストークンをURIフラグメントに仕込む
    • クライアントサイドJavaScriptでURIフラグメントをパースしてアクセストークンを取得
    • これ以降は、クライアントサイドJavaScriptから、クロスドメイン通信でクエリパラメータにアクセストークンを含めてWeb APIを呼ぶ

前へ | 次へ



以上の内容はhttps://am1tanaka.hatenablog.com/entry/2015/02/13/235800より取得しました。
このページはhttp://font.textar.tv/のウェブフォントを使用してます
不具合報告/要望等はこちらへお願いします。
モバイルやる夫Viewer Ver0.14