RESTful Web APIs 読書メモ(4)

Chapter.4 Hypermedia

  • ハイパーメディア

    • リソースを互いに結びつけ合わせること
    • 将来発行することになるリクエストをサーバーがクライアントに伝える方法
    • あたかもメニューのようなもの
  • ハイパーメディアとしてのHTML

    • リンクを選択すること = リンク先のリソースに"visit"すること
      • 表示されたリソースを新しいリソースで置き換えること
    • aタグ
      • あるURLに対して、リンクを選択した場合のみ発行されるGETリクエストを発行するもの
      • imgタグ
        • あるURLに対して、バックグラウンドで自動的にGETリクエストを発行するもの
      • formタグ(method=POST)
        • あるURLに対して、submitした場合に、クライアントが生成したエンティティボディをもつPOSTリクエストを発行するもの
      • formタグ(method=GET)
        • submitした場合に、クライアントが生成したクエリボディをもつURLにGETリクてを発行するもの
        • human-readableなURLは作られない
        • RFC6570, URI Templateを使うと、human-readableにできる
  • URIとURLの違い

    • URL
      • リソースを見分けるための短い文字列
      • URLはURIの一種
      • RFC3986で標準化
      • 何らかの表現と関連づいてる
    • URI
      • リソースを見分けるための短い文字列
      • RFC3986で標準化
      • 表現をもつ保障はない
      • URNもURIの一種
    • URLなしでは、リソースを表現として得られない -> REST制約を満たせない
    • URNでリンクをつくってもハイパーメディア制約を満たせない
    • URLであれば、REST制約を満たせる
  • HTTPリクエストやレスポンスのLINKヘッダ(RFC5988)

    • 画像やただのplain textをハイパーメディアを付与する
      • 画像であればスライドショー
      • テキストであれば、本文の続き
  • ハイパーメディアの仕事

    • クライアントにHTTPリクエストの構築方法を伝達
      • aタグ: メソッド(暗黙的)とURL(明示的) を提示している
      • formタグ: メソッド、URL、送信本文を提示
        • encType属性を付与することでContent-Typeヘッダを提示できる
      • URI Template: URLを提示
    • HTTPレスポンスについての約束事をとりつける
      • imgタグ:
        • aタグ同様GETリクエストとなることを提示
        • サーバーがレスポンスとして画像を返すことを約束づけている
      • AtomPubのlinkタグ
        • rel="edit"の付与で、GETに加えPUT, DELETEのサポートを約束づけている
        • AtomPub Member Entity表現がレスポンスとして返されることを約束づけている
    • ワークフロー制御の提案
      • リソース間の関係を提示
        • aタグ
          • 現在のページから指定されたURLのページに移動する
          • out-bound リンク(アプリケーション状態を変化させる)
        • imgタグ
          • embeddedリンク(アプリケーション状態を変化させない)
        • scriptタグ
          • 表現をダウンロードし、実行
        • link rel="stylesheet"
          • スタイルシートを適用する
        • framesetタグ
          • 別のhtmlドキュメントを埋め込む
  • ハイパーメディアの偽物にご用心

    • JSONはハイパーメディアをサポートしていない。
    • URLに見えても、仕様上、所詮ただの文字列
    • web APIのレスポンスとして生JSONを使用することはREST制約を満たせない
    • web APIのレスポンスにはハイパーメディアをサポートするmedia typeを使うべき
  • imgタグとscriptタグもGETでリソース表現を取得する点でプロトコルセマンティクスや違いはない

  • 各々のタグから導かれるアプリケーションセマンティクスに従って処理を行う

Semantics Challenge

  • Webブラウザは、人との対話を通してリンク先を決定する
  • いかにすれば、人の介在なしにこの振る舞いを実現できるのか?

  • HTMLのimgタグも、scriptタグも、HTTPの観点では違いはない

    • 同一のプロトコルセマンティクスを持つ
    • アプリケーションセマンティクスは異なるが・・・
  • ドメイン特化アプリの場合、ハイパーメディアコントロールがセマンティクスギャップを埋める可能性を持つ

    • 画像収集アプリであれば、imgタグだけを踏み、scriptタグを無視する

つづき・・・

RESTful Web APIs 読書メモ(5)