Bonkura - Kenny

SIerで働く文系SEの記録

【読書メモ】Webを支える技術

せっかく読み込んだ本の内容を忘れないようにするのと、
読んだ本を明確に記録するという目的で、
読書メモをブログにアウトプットしていくことにした。

最初はかの有名な「Webを支える技術」にする。

Webを支える技術 -HTTP、URI、HTML、そしてREST (WEB+DB PRESS plus)

Webを支える技術 -HTTP、URI、HTML、そしてREST (WEB+DB PRESS plus)

はじめに


Webは2つの側面を持つ
・ハイパーメディアシステム
→単方向リンクのみ扱う。シンプル故に普及した。
・分散システム
→世界中に配置されたサーバに世界中の"様々な"ブラウザからアクセスする、という分散システム
→クライアントサーバ間のインタフェースをHTTPというシンプルなプロトコルで固定した事で実現出来た。

REST


→Webのアーキテクチャスタイル(複数アーキテクチャに共通する性質・様式・作法)
システムのアーキテクチャを決定する際の羅針盤となる。

・クライアント/サーバから派生している。クライアント/サーバアーキテクチャスタイルに、"制約"を加えていくとRESTになる。

クライアント/サーバ :ユーザインタフェースと処理を分離
ステートレスサーバ :サーバ側でアプリケーション状態を持たない(セッション管理等もちろん例外もあり)
キャッシュ :クライアントとサーバの通信回数・量を減らす。
統一インタフェース :インタフェースを固定する(HTTP1.1ではメソッドは8個だけ)
階層化システム :システムを階層に分離
コードオンデマンド :プログラムコードをサーバからダウンロードし、クライアント側で実行する(JavaScript

リソース?→Web上に存在する、名前を持ったありとあらゆる情報
・リソースを簡単に指し示せる性質の事を「アドレス可能性」と呼ぶ。
・リソースは複数の"リソースの表現"を持てる。(JSONでもhtmlでも見れる)

URI


URI・・・統一リソース識別子(リソースを統一的に識別する)
→インターネット上で必ず一意になるホスト名の仕組みと、ホスト内で必ず一意になる階層的なパスを組み合わせる!

URIフラグメント(~.html#10)
→リソース内部の更に細かい部分を特定する時に使う。

URI設計の注意点
・相対URIの扱い :なるべく絶対URIを使う
・%エンコーディングの扱い;UTF-8を使う

URIはURLとURNを総称する名前

・Cool URLs don't change
→クールなURIは変わらない。そのためには?

1.プログラミング言語に依存した拡張子やパスを含めない
2.メソッド名やセッションIDを含めない
3.URIはリソースを表現する名詞にする

・マトリクスURI
→階層構造で表現出来ない時に複数のパラメータの組み合わせでリソースを表現する
ex) GoogleMap

HTTP

クライアント/サーバ
リクエスト/レスポンス型

・HTTPメッセージ(リクエストメッセージ・レスポンスメッセージ)

                                  • -

①リクエスト・メッセージ
■リクエストライン
メソッド
・リクエストURI
プロトコルバージョン
■ヘッダ…メッセージのメタデータ
■ボディ

                                  • -

②レスポンスメッセージ
■ステータスライン
プロトコルバージョン
ステータスコード
・テキストフレーズ
■ヘッダ
■ボディ

                                  • -

ステートレス性…サーバがクライアントのアプリケーション状態を保存しない制約

・ステートフルの欠点
複数のサーバ間でアプリケーション状態を同期する必要あり→オーバヘッドが無視できない→スケールアウトし辛い

・ステートレスの欠点
→送信するデータ量が多い(自己記述的)

HTTPメソッド


GET…リソースの取得
POST…リソースの作成・追加
①あるリソースに対する小リソースの作成
②既存リソースへのデータの追加
③他のメソッドでは対応出来ない処理(GETではURIに含めていたキーワードをリクエストボディに入れる)
PUT…リソースの更新・作成
DELETE…リソースの削除
HEAD…リソースのヘッダの取得
OPTIONS…リソースがサポートとしているメソッドの取得

※POSTとPUTの使い分け
→リソースのURIをどちらかが作成するか?(POST:サーバ、PUT:クライアント)基本的にはPOST

※HTMLのフォームで指定出来るメソッドはGETとPOSTのみ

※条件付きリクエスト
ex) リソースがこの日時以降更新されていたら取得する。

※べき等(ある操作を何回行っても結果が同じ)と安全(操作対象のリソースの状態を変化させないこと)
GET・HEAD :べき等かつ安全
PUT・DELETE :べき等だが安全でない
POST :べき等でも安全でもない

ステータスコード
1xx 処理中
2xx 成功
3xx リダイレクト
4xx クライアントエラー
5xx サーバエラー

・HTTPヘッダ

Content-Type:そのメッセージのボディの内容がどのような種類なのか?
charset :文字エンコーディング
Date :日付
Content-Length :ボディの長さを指定する
Transfer-Encoding :chunked →ボディを少しづつ転送
などなど

・認証

Basic認証 :ユーザ名とパスワードによる認証 ユーザ名とパスワードを:で連結しでBase64エンコードしたもの。
→簡単にデコード可能=ユーザ名とパスワードが平文で流れることになる
Diget認証 :Basic認証よりセキュア

・KeepAlive
→クライアントとサーバ間でリクエストのたびに切断するのではなくまとめて接続し続ける

HTML


→タグで文書の構造を表現するコンピュータ言語

・HTMLのメディアタイプ
「text/html」「application/xhtml+xml

リンク設計の際には
「リンクをたどることでアプリケーションの状態が遷移する」
を強く意識する。重要な設計指針。

microformats


HTMLの中で更に意味のあるデータを表現するための技術
セマンティックWebを実現する
Webにおける意味論…リソースが持つ意味を確定させるための理論
→HTMLやXMLで書かれたリソースの意味をどのようにプログラムから処理するか?
=人間が読んで理解するWebページの意味を、プログラムから処理出来るように形式的に意味を記述するための技術
microformats(HTML文書そのものにメタデータを埋め込む技術)
プログラミング言語が持つ意味を確定させるための理論=プログラム意味論
ex) コンパイラ

JSON


軽量なデータ表現形式。JacaScriptの記法でデータを記述する。
プログラミング言語間でデータを受け渡す事が可能。
Ajax通信におけるデータ・フォーマットとして活用されている。
メディアタイプは「application/json

組み込みで用意されているデータ型
・オブジェクト
→名前と値の集合 名前と値の組をオブジェクトのメンバと呼ぶ
・配列
→順序を持った値の集合
・文字列
→必ず""で囲む。
・数値
ブーリアン
・null

・クロスドメイン通信(JSONP
…不特定多数のドメインに属するサーバにアクセスすること
ブラウザで入力した情報を不正なサーバに送信出来てしまう為、セキュリティ上の制限から普通は出来ない…

リソース設計

→どのようにリソースを分割し、URIで名前を付け、相互にリンクをもたせるか?
WebサービスとWebAPIを分けて考えないこと!

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

※1と2が難しい…

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


・リソースの作成
ファクトリリソース(リソースを作成するための特別なリソース)へPOST
PUT
・リソースの更新
ルクアップデート(更新したいリソース全体をそのままPUT)
パーシャルアップデート(部分的なデータをPUT)
・リソースの削除
バッチ処理
トランザクションリソース(トランザクション情報を表現するリソース)
トランザクションリソースをPUT→トランザクションリソースにPUT→実行→トランザクションリソースを削除



以上。仕事で触れる事が少ないので理解が甘いが、
Webは興味のある分野なので、しっかりと覚えておきたいところ。