Skip to content

Instantly share code, notes, and snippets.

@keisuke-umezawa

keisuke-umezawa/webを支える技術3章.md

Last active November 21, 2016 13:32
Show Gist options
  • Save keisuke-umezawa/e2a074690acad69574cbac9f4c931cac to your computer and use it in GitHub Desktop.
Save keisuke-umezawa/e2a074690acad69574cbac9f4c931cac to your computer and use it in GitHub Desktop.
Download ZIP
http://amzn.asia/1ztHgfS の読書ログ
Raw
webを支える技術3章.md

3章 REST

アブストラクト

  • Webは以下の特徴を持つ
    • ハイパーメディア
    • 世界規模の分散システム
  • 上記の成功を収めたのは、Webの設計思想RESTによる

3.1 アーキテクチャスタイルの重要性

  • RESTはWebのアーキテクチャスタイル
  • アーキテクチャスタイルとは？
    • 別名「マクロアーキテクチャパターン」
      • デザインパターンは別名「マイクロアーキテクチャパターン」
    • アーキテクチャを設計するときの、指針・作法・流儀

3.2 アーキテクチャスタイルとしてのREST

  • RESTはネットワークシステムのアーキテクチャスタイル
    • ex. クライアント/サーバなども
  • RESTはクライアント/サーバに制約をつけたもの
  • 抽象化レベルの関係
抽象化レベル Webでの例
アーキテクチャスタイル REST
アーキテクチャ プラウザ、サーバ、プロキシ、HTTP、URI、HTML
実装 Apache、Firefox、IE
  • RESTの原則[1]
    1. ステートレスなクライアント/サーバプロトコル
    2. すべての情報（リソース）に適用できる「よく定義された操作」のセット
    3. リソースを一意に識別する「汎用的な構文」
    4. アプリケーションの情報と状態遷移の両方を扱うことができる「ハイパーメディアの使用」

3.3 リソース

  • リソース
    • Web上に存在する、識別子をもったありとあらゆる情報
  • リソースの識別子
    • URIのこと
  • リソースとURIのまとめ
    1. リソースとはweb上の情報
    2. 世界中の無数のリソースは、それぞれURIで一意の名前を持つ
    3. URIを用いることで、プログラムはリソースが表現する情報にアクセスできる
  • リソースのアドレス可能性
    • URIなどが備える、リソースをかんたんに指し示せる性質のこと

3.4 スタイルを組み合わせてRESTを構成する

  • RESTは複数のアーキテクチャスタイルを組み合わせて構築した複合アーキテクトスタイル
  • クライアント/サーバに他のアーキテクチャによる制約を課すことで説明する

クライアント/サーバ

  • クライアントがリクエストを送り、それにサーバがレスポンスを返すスタイル(メッセージパッシング)
  • 利点
    1. 管理者に取ってサービス管理が容易
    • クライアントをマルチプラットフォームにできる
    • 分散処理、冗長化可能
    • 機能が分離できる
      • UIはクライアントで決めれば良い
      • サーバはデータストレージとしての機能さえ持てば良い
    1. クライアントの計算機資源への負荷減少
  • 欠点
    1. Single Point of Failure
    2. サーバの計算機資源への負荷集中
    3. サーバまでのネットワーク資源への負荷集中
  • その中でも、RESTは統一IFを追加した「統一/クライアント/キャッシュ/ステートレスサーバ」

ステートレスサーバ

  • クライアントのアプリケーション状態をサーバで管理しないこと
  • 利点
    • リクエストに答えたらすぐにサーバの計算機リソースを開放できる
  • 欠点
    • Cookieなどのセッション管理はステートフル
  • ステートレス性を追加したアーキテクチャスタイルを「クライアント/ステートレスサーバ」という

キャッシュ

  • 一度取得したリソースをクライアント側で使いまわす方式
  • 利点
    • サーバとクライアント間の通信回数をへらす
  • キャッシュを追加したアーキテクチャスタイルを「クライアント/キャッシュ/ステートレスサーバ」という

階層化システム

  • 統一IFを導入することで階層化可能
  • 利点
    • 階層化しやすい
      • ex. ロードバランサー、プロキシを入れられる
  • 階層化システムを追加したアーキテクチャスタイルを「統一/階層化/クライアント/キャッシュ/ステートレスサーバ」という

コードオンデマンド

  • プログラムコードをサーバからダウンロードし、クライアント側で実行するアーキテクチャスタイル。
    • ex. JavaScript、Flash、Javaアプレット
  • 利点
    • クライアントを後から拡張できる
  • 欠点
    • ネットワーク通信におけるプロトコルの可視性が低下する
      • HTTPでリソースにアクセスする以上のことをしており、よくわからなくなる
  • コードオンデマンドを追加したアーキテクチャスタイルを「統一/階層化/コードオンデマンド/クライアント/キャッシュ/ステートレスサーバ」という

結局RESTとは

  1. クライアント/サーバ：UIと処理を分離する
  2. ステートレスサーバ：サーバ側でアプリケーション状態を持たない
  3. キャッシュ：クライアントとサーバの通信回数と量を減らす
  4. 統一IF：IFを固定する
  5. 階層化システム：システムを階層に分離する
  6. コードオンデマンド：プログラムをクライアントにDLして実行する
  • 他のアーキテクチャスタイルの例[2]
    • メッセージパス
    • レイヤ・アーキテクチャ
    • SOA
    • P2P
    • プラグイン
    • パブリッシュ/サブスクライブ
    • パイプ＆フィルタ
    • フロントエンド/バックエンド

リファレンス

Raw
webを支える技術5章.md

5章 URI設計

良いURIとは

  • 変更が少ない

良いURI設計に必要なものは？

  1. プログラミング言語に依存した拡張子やパスを含めない
  • ex. http://expample.jp/cgi-bin/login.pl、http://expample.jp/servlet/LoginServlet
  1. メッソド名やセッションIDを含めない
  • ex. http://expample.jp/Login.do?action=showPage、http://expample.jp/home.jsp?jsessionid=12345678
  1. URIはリソースを表現する名刺にする
  • ex. http://expample.jp/sample/people/show/123->http://expample.jp/sample/people/123

URIを変更したい時

  • リダイレクトする

URI設計のテクニック

  • 拡張子で表現を指定する ex. jpで日本語、enで英語
  • マトリックスURI ex. https://www.google.co.jp/maps/@lat=32.9998961,lng=138.4293071
Raw
webを支える技術5部.md

15章 読み取り専用のWebサービスの設計

  • リソース設計にほかならない
  • リソース設計に必要なもの
    1. URI設計
    2. 表現選択の指針
    3. リンク設計

16章 書き込み可能なWebサービスの設計

書込み可能なWebサービスの難しさ

  • 同時書き込みへの対応
  • 同時に複数のリソースの更新への対応
  • 複数の処理手順を必ずセットで行う対応

書き込み可能な郵便番号サービスの設計

  • 追加する機能は以下
    • 郵便番号リソースの作成
    • 郵便番号リソースの更新
    • 郵便番号リソースの削除
    • バッチ所為
    • トランザクション
    • 排他制御

リソースの作成

ファクトリリソースへPOSTする方法

  • ファクトリリソース
    • リソースを割く聖羽するための特別なリソース
  • そのリソースに対してPOSTすることでリソースを作成するようにする

PUTで直接編集する方法

  • 直接Jsonコード等を編集するようにする
  • メリット
    • POSTをサポートする必要がなく、サーバ側の実装が簡単
    • クライアントが作成と更新を区別しなくて良くなるので、クライアント側の実装が簡単
  • デメリット
    • クライアントがURIの構造を把握していないといけない
    • リクエストの見た目では、更新か作成か判断できない

リソースの更新

  • PUTで行う
  • バルクアップデート
    • 全体を更新する
  • パーシャルアップデート
    • 一部分を更新する

リソースの削除

  • DELETEで行う

バッチ処理

  • ファクトリリソースに複数のデータを入れてPOSTで行う

トランザクション

  • 複数の処理のセットにおいて、全部処理が成功するか、もしくは元の状態に戻して失敗させる。

トランザクションリソース

  • トランザクションの情報を表現するリソース
  • 以下の順序で行われる
    1. トランザクションの開始(POST transactions -> 201 Created transactions/308)
    2. 処理対象の追加(PUT transactions/308/1 -> 201 Created transactions/308/1)
    3. トランザクションの実行(PUT transactions/308 -> 200 OK)
    4. トランザクションリソースの削除(DELETE transactions/308 -> 200 OK)

トランザクションリソース以外の解決方法

  • バッチ処理による解決

排他制御

解決すべき問題

  • 同時に1つのリソースを編集しようとした場合

悲観的ロック

  • WebDAVのLOCK/UNLOCK
  • 独自のロックリソース

楽観的ロック

  • 競合が起きたときに対応する
  • 方法
    • 条件付きPUTで
    • 条件付きDELETE
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment