【まとめ】「Webを支える技術 HTTP,URI,HTML,そしてREST」を読んだ
こんにちは、Hinataです。
「Webを支える技術 HTTP,URI,HTML,そしてREST」を読みました。
読んだ内容をまとめたいと思います。
定性すべき箇所あれば、ご指摘いただけると本人のためにもなりますので、
よろしくお願いしますm(_ _)m
この本を読んだ目的
Webフレームワーク、WebAPIの中の仕組みを理解するため
フレームワークやAPIは複雑な手順が隠蔽されており、自動化されているから、その中を理解したかった
Web概論
Webとは何か
WebはHTTPとURIとHTMLで構成されている。
Webはハイパーメディアシステムと分散システムという２つの側面を持っている。
Webの用途
Webサイト
UI（ユーザインターフェース）デバイスの設定画面
WebAPI
リクエスト(キーワード絞り込み等)を送ると、情報がXMLやJSON、RSS形式等で出力されて帰ってくる。(XML、JSON形式を採用しているAPIが多い。)
そのあとXMLやJSON形式のデータをいじって人が見やすいHTMLに整える。
その時PHPとかJavascript等のプログラミング言語を用いる。
PHPとかで自動リクエスト⇒自動で取得⇒自動でHTML表示するように仕組みを作る。
REST-Webのアーキテクチャスタイル
RESTはシンプルでできるだけクライアントとサーバ間で通信を少なくした仕組み。
RESTは以下の特徴を備えたアーキテクチャスタイル。
クライアント/サーバ…ユーザインターフェースと処理を分離する
ステートレスサーバ…サーバ側でアプリケーション状態を持たない
キャッシュ…クライアントとサーバの通信回数と量を減らす
階層化システム…システムを階層に分離する
コードオンデマンド…プログラムをクライアントにダウンロードして実行する
キーワード整理：
アーキテクチャスタイル…REST
アーキテクチャ…サーバ、ブラウザ、プロキシ
実装…firefox,Apache,InternetExplorer
リソース…情報（東京の天気予報等）
URI…リソースの名前
URIを用いることで、プログラムはリソースが持つ情報にアクセスできるようになる
ステートレスサーバ…クライアント側のアプリケーション状態をサーバで管理しない
HTTPをステートフルにする代表格はCookie
キャッシュ…リソースの鮮度に基づいて、一度獲得したリソースをクライアント側で使いまわす方式のこと。
サーバとクライアントの間の通信料を減らす役割がある。
コードオンデマンド…プログラムコードをサーバからダウンロードし、クライアント側でそれを実行するアーキテクチャスタイルのこと。JavascriptやFlash
オーバーヘッド…追加的に発生する処理（負荷）
URI
Webにあるリソースは、全てURIで示すことができ、かつHTTPで操作できる。
HTTP
HTTPの基本
HTTPはTCP/IPをベースとした、Webの基盤となるプロトコル
インターネットのプロトコルは階層性になっている。
アプリケーション層:HTTP,NTP,SSH,SMTP,DNS
トランスポート層:UDP,TCP（データの抜け漏れをチェックし、データの到達を保証する）
インターネット層:IP（ネットワークでデータを実際にやり取りする。データを送るのみ）
ネットワークインターフェース層:物理的なケーブルとネットワークアダプタ
TCPで接続したコネクションで転送するデータが、どのアプリケーションに渡るかを決定するのがポート番号。
TCPでプログラムを作るときは、ソケットというライブラリを使うのが一般的。ソケットはネットワークでのデータのやり取りを抽象化したAPIで、接続、送信、受信、切断などの基本的な機能を備えています。HTTPサーバやブラウザはソケットを用いて実装する。
今はどの言語でもHTTPを実装したライブラリがついているから、ソケットを用いてHTTPを実装することはないが。。。
HTTPはステートレスなプロトコルとして設計されている
ステートレスとは、サーバがクライアントのアプリケーション状態を保存しない制約のこと。
ステートレスなアーキテクチャでは、クライアントは、リクエストの処理に必要な情報がすべて含まれているメッセージ「自己記述的メッセージ」を送信する。
ステートレスの利点
・クライアントが自らのアプリケーション状態を覚えているので、サーバの処理が少ない
ステートレスの欠点
・パフォーマンスの低下
・通信エラーへの対処
（ステートレスなアーキテクチャでは、ネットワークトラブルが起きたときにそのリクエストが処理されたかどうかがわからない。）
ハイパーメディアフォーマット
WebAPIを開発するときには、Webサービスの特性に合わせてベースとなるプロトコルやデータフォーマットを選ぼう。
HTML
HTMLは、タグで文書の構造を表現するコンピュータ言語である、マークアップ言語の一つ。ただ、人がブラウザで読むために利用しているため、プログラムでの処理が難しいというデメリットがある。
Atom
汎用XMLフォーマット
JSON
データ構造の記述が得意。Ajax（ウェブブラウザ内で非同期通信を行いながらインターフェイスの構築を行うプログラミング手法）では必須の技術
上３つよりもより軽量なデータ表現形式
記法はJavascriptですが、多くの言語でライブラリがあるために言語間でデータを受け渡すことが可能
Webサービスの設計
リソース設計において重要なこと
WebサービスとWebAPIを分けて考えないこと
リソース設計に必要なスキル
・URI設計方法
・最適な表現選択
・リンクの設計
読み取り専用のWEBサービスの設計
例：郵便番号検索サービス
リソース指向アーキテクチャのアプローチをもとに設計してみる
1.Webサービスで提供するデータを特定する
2.データをリソースに分ける
※実はここが一番重要
最適なリソース分割にすること。
リソース分割については下記
3.リソースにURIで名前をつける
4.クライアントに提供するリソースの表現を設計する
Webの代表的な表現方式
リソースや設計に合わせた表現方式を選ぶ
5.リンクとフォームを利用してリソース同士を結びつける
6.イベントの標準的なコースを検討する
7.エラーについて検討する
書込み可能なWebサービスの設計
書き込み可能なWebサービスを作るとき考えるべきこと
バッチ処理
リソースを一括で送信すること。
トランザクション
複数のリソースのまたがった変更をひとまとまりに行うこと。
片方のリソースの変更が成功して、もう片方が失敗したりしないように、2つとも処理が成功するか、もしくは２つとも失敗するようにする。
排他制御
複数のクライアントが一度に一つのリソースを編集して競合が起こらないように、一つのクライアントのみが編集するよう制御する処理のこと。
悲観的ロック
ユーザをあまり信頼せずに、競合が発生しないようにする排他制御の方法
ロックの権限を持っている人しか編集できない
楽観的ロック
通常の編集では文書をロックせずに競合が起きたときだけ対処する
リソースの設計
リソース指向アーキテクチャの設計アプローチの罠
「Webサービスで提供するデータを特定」し、「データをリソースに分ける方法」が確立されていないこと
現状は以下を用いるといい
・関係モデルとオブジェクト指向モデルを組み合わせる
関係モデル
中心となるテーブルが持っている属性をリソースに持たせて、リソースが持つデータを検討する
オブジェクト指向モデル
クラスのメゾットを操作結果リソースと考えてリソースを分けてみる
図書館情報学の観点からデータを切り分ける
わかったこと
ネットワークの構造
Webアプリの内部構造や、設計方法
初心者で、WEBフレームワークやAPIについて理解したい人にはおすすめです！
