Webを支える技術 第5部 まとめ

Webを支える技術 第5部 まとめ

#Webサービスの設計
WebサービスやWeb APIの設計では、HTTPやRESTだけなく様々な知識が必要になってくる。

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

WebサービスやAPIの設計には、システム全体の設計や内部クラス、DBといったような広範囲に渡る設計が必要になってくる。

###リソース設計とは
その中でもリソース設計とは、以下のようなクライアント-サーバ間のインターフェースの設計を指す。(URIの命名、リソースの分割など)

尚リソースを設計する際には、「人間向けののWebサービス」と「プログラム向けのWeb API」を分けずに設計することが重要になってくる。(分けて設計すると機能が違ったものになりがち)

###リソース指向アーキテクチャのアプローチ
以下は「リソース指向アーキテクチャ」に基づいた開発アプローチである。

1. Webサービスで提供するデータを特定する
2. データをリソースに分ける
3. リソースにURIで名前を付ける
4. クライアントに提供するリソースの表現を設計する
5. リンクのフォームを利用してリソース同士を結び付ける
6. イベントの標準的なコースを検討する
7. エラーについて検討する

1. Webサービスで提供するデータを特定する

リソース設計の最初の工程であり、サービスで提供するデータを特定する作業。

2. データをリソースに分ける

1で特定したデータをリソースとして分割する作業。
何をもってリソースとするか、リソースをどのような単位で分割するかなど非常に重要な取り決めを行う工程である。
また、最適なリソース分割を行うため、この工程を何回も繰り返すのが一般的である。

###3. リソースにURIで名前を付ける
リソースにURIを命名する作業。
WebサービスやAPIを利用する相手にとって、なるべく使いやすいURIを検討することが重要である。

###4. クライアントに提供するリソースの表現を設計する
リソースの表現形式を設計する作業。
表現形式には以下のようなものが挙げられる。

• XML表現
  • XHTML
  • Atom
  • 独自XML
• 軽量フォーマット表現
  • JSON/JSONP
  • YAML
  • CSV
• マルチメディア表現
  • 画像(jpg,png,bmp,gif)
  • 映像(mp4,wmv,avi,webm)
  • マルチページ(pdf,tiff)

各表現形式には得意不得意があり、1つのリソースが複数の表現形式に対応していると便利。

###5. リンクのフォームを利用してリソース同士を結び付ける
1~4で設計してきたリソース同士をリンクで接続する。
通常のWebページでは、トップページへのリンクやパンくずリスト、グローバルナビゲーションを用意しておくことで、クライアントが他のリソースに移動しやすく設計されていることが多い。

###6. イベントの標準的なコースを検討する
利用者がどのようなフローで利用するか検討する。

###7. エラーについて検討する
利用時に起こりうるエラーの検討。

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

最近のWebサービスは、何らかの形で書き込み機能があるものがほとんどである。
書き込み機能を実装する場合、読み取り専用のサービスと比較して、より多くの処理を考えなければならない。

###リソースの作成
リソースの作成にはHTTPの「POST」もしくは「PUT」を使う方法があり、一般的にはPOSTを使う方が無難。

###リソースの更新
リソースの更新に置いては「PUT」で行う。但し、バッチ処理を行う際には「POST」を利用する。

###リソースの削除
削除したいリソースのURIに「DELETE」を送ることで削除できる。
削除設計においての注意点は、親子関係にあるリソースの削除についてである。一般的には親リソースを削除した場合、付随して子リソースも削除すべき。

###バッチ処理
処理を大量に行う場合、一つ一つリクエストを送信していてはサーバに負荷がかかってしまう。これはリクエストを一括して送信(バッチ処理)する機能を実装することで解決できる。(POSTで送信)

###トランザクション
トランザクションは複数のリソースにまたがって行う処理を一つの処理として扱うことで、「一つでも処理に失敗したら全て失敗」というような一貫性を保証する。

###排他制御
複数のクライアントが一つのリソースを変更しようとした際に、競合を起こさないよう一つのクライアントのみが変更できるように制御する処理。大きく分けて「悲観的ロック」と「楽観的ロック」の二つがある。

• 悲観的ロック

  • ユーザをあまり信用せず、絶対に競合が発生しないように制御する方法

• 楽観的ロック

  • 悲観的ロックに対して、競合が起きたときにのみ排他制御をする方法

##設計のバランス

• なるべくシンプルに保つ

  • 設計が複雑になったり無駄な機能が増えてきた場合、一段階メタな視点で全体を考え直すこと。
  • 全体をシンプルに保つことは、設計のバランスにおいて最も重要

• 困ったらリソースに戻って考える

  • HTTPメソッドで実装出来ない機能があると感じたら、独立した別リソースで代替できないか検討する

• 本当に必要ならPOSTで何でも出来る

  • PUTの方が処理が簡単になるとしても、バッチ処理などで複数のリソースが対象になった時点で、POSTにシフトした方が賢明である。

第17章 リソースの設計

##リソース指向アーキテクチャの落とし穴

第15章の「リソース指向アーキテクチャ」にある

1.Webサービスで提供するデータを特定
2.データをリソースに分ける

について何を基準にこれらを行っていくのかが曖昧である。

この基準を明確にするため、既存の設計手法で得られる以下の成果物を元にリソースを設計する。

• 関係モデルのER図
• オブジェクト指向モデルのクラス図
• 情報アーキテクチャ

###関係モデルからの導出
関係モデルはRDBMSの基礎となっているデータモデルで、データの正規化の手法が確立されているため、効率的なDB設計を行える。

###オブジェクト指向モデルからの導出
オブジェクト指向設計の成果物であるクラス図やシーケンス図を使い、リソースの導出を検討する。

###情報アーキテクチャからの導出

情報アーキテクチャは、知識やデータの組織化を意味し「情報を分かりやすく伝える」「受け手が情報を探しやすくする」といったことを実現するための表現技術

難易度は高いがWebデザインにおける

• ユーザの操作
• ページ遷移
• ネットワーク通信
• アプリケーションの実行

などといった複雑なデザインをリソースの設計と共に整理して、ユーザビリティを高めることが可能である。

##リソース設計で最も重要なこと
リソース設計する際に、WebサービスとWeb APIを分けて考えないことが最も重要である

##※参考
・Webを支える技術
https://www.amazon.co.jp/dp/4774142042/ref=cm_sw_em_r_mt_dp_U_LiIUEbQ3NJSJH