はじめに
webの理解力を深めるために復讐とアウトプットの練習を兼ねて
第1部
第1章 Webとは何か
- webサイト
- ユーザーインタフェース
- プログラム用のAPI
第2章 Webの歴史
SOAPとは...RPC(分散オブジェクトグループ)の動きの中で最も基本的なプロトコル
第3章 REST、webのアーキテクチャスタイル
RESTとは
- クライアントサーバ:ユーザインタフェースと処理を分離する
- ステートレスサーバ:サーバ側でアプリケーション状態を持たない
- キャッシュ:クライアントとサーバの通信回数と量を減らす
- 統一インタフェース:インタフェースを固定する
- 階層化システム:システムを階層に分離する
- コードオンデマンド:プログラムをクライアントにダウンロードして実行する
第2部 URI
第2章 URIの仕様
URI...Uniform Resource Identifier(統一リソース識別子)
例)http://blog.example.jp/entries/1
上記の例のURIを構成するパーツ
- URIスキーム:http
- ホスト名:blog.example.jp
- パス:/entries/1
URIスキームは、そのURIが利用するプロトコルを示すのが一般的
ホスト名は、DNS(Domain Name System)で名前が解決できるドメイン名かIPアドレスで、インターネット上で必ず一意になる
URIで使用できる文字
- アルファベット:A-Za-z
- 数字0-9
- 記号:-.~:@!$&'()
%エンコーディングでその文字をエンコードする
WebサービスやWeb APIを実装する場合は、なるべく絶対URIを使う
第2章 URIの設計
URIの設計指針
- URIにプログラミング言語依存の拡張子を利用しない
- URIに実装依存のパス名を利用しない
- URIにプログラミング言語のメソッド名を利用しない
- URIにセッションIDを含めない
- URIはそのリソースを表現する名詞である
URIを変更する場合は新しいURIにリダイレクトするようにしよう
URIは次の点を意識する
- URIはリソースの名前である
- URIは寿命が長い
- URIはブラウザがアドレス欄に表示する
第3部 HTTP
第6章 HTTPの基本
HTTPはTCP/IPをベースとしたプロトコル
HTTPはコンピュータで扱えるデータであればなんでも転送可能
HTTPはRESTの重要な特徴である統一インターフェース、ステートレスサーバ、キャッシュなどを実現している、Webの基盤となるプロトコルです
HTTPはTCP/IPをベースにしている
TCP(Transmission Control Protocol)とIP(Internet Protocol)は、インターネットの基盤を構成する重要なネットワークプロトコル
階層型プロトコルである
ネットワークインターフェース層
- 一番下のネットワークインターフェース層は、物理的なケーブルやネットワークアダプタに相当する部分
インターネット層
- ネットワークインターフェース層の上、ネットワークでデータを実際にやり取りする部分で、TCP/IPのIPに相当する。IPではデータの基本的な通信単位を「パケット」(packet)と呼び、指定したIPアドレスを送り先として、パケット単位でデータをやり取り通信する。IPは自分のネットワークインターフェースでデータを送り出すことだけ保証し、最終的に届くかは保証しない。
トランスポート層
- インターネット層の上の層、TCP/IPのTCPの部分でIPが保証しなかったデータの転送を保証するのがトランスポート層。TCPでは接続先の相手に対してコネクションを張る。このコネクションを使ってデータの抜け漏れをチェックし、データの到達を保証する。
- TCPで接毒したコネクションで転送するデータが、どのアプリケーションを渡るかを決定するのがポート番号で、1〜65535の数値でサーバ側でよく使われるポート番号にはデフォルトの番号が割り当てられており、HTTPはデフォルトで80番ポートを使用する。
アプリケーション層
- トランスポート層の上の層、具体的なインターネットアプリケーション(メールやDNS、HTTPを実装する層)
- TCPでプログラムを作るときは、ソケット(socket)と呼ばれるライブラリを使うのが一般的。
- ソケットはネットワークでのデータのやり取りを抽象化したAPIで、接続、送信、受信、切断などの基本的な機能を備えている
- HTTPサーバやブラウザはソケットを用いて実装する
クライアントで行われること
1.リクエストメッセージの構築
2.リクエストメッセージの送信
3.(レスポンスが返るまで待機)
4.レスポンスメッセージの受信
5.レスポンスメッセージの解析
6.クライアントの目的を達成するために必要な処理
サーバで行われること
1.(リクエストの待機)
2.リクエストメッセージの受信
3.リクエストメッセージの解析
4.適切なアプリケーションプログラムへの処理の委譲
5.アプリケーションプログラムから結果を取得
6.レスポンスメッセージの構築
7.レスポンスメッセージの送信
リクエストメッセージ
-
リクエストライン
リクエストメッセージの1行目は「リクエストライン」と呼び、メソッド(GET)、リクエストURI(/test)、プロトコルバージョン(HTTP/1.1)から成る -
ヘッダ
リクエストメッセージの2行目以降はヘッダが続く。メッセージのメタデータ -
ボディ
ヘッダの後に続く。本質的な情報が入る
レスポンスメッセージ
-
ステータスライン
レスポンスメッセージの1行目は「ステータスライン」と呼びプロトコルバージョン、ステータスコード、テキストフレーズから成る -
ヘッダ
レスポンスメッセージの2行目以降は、リクエストメッセージと同様にヘッダ -
ボディ
このレスポンスメッセージにはボディも含まれる、ヘッダとボディは空行で区切られる
ステートフルなサーバはアプリケーション状態を覚える必要がある
ステートレスなサーバはアプリケーション状態を覚える必要がない
ステートレスの欠点
パフォーマンスの低下
- 送信するとデータ量が多くなる
- 認証など、サーバに負荷がかかる処理を繰り返す
通信エラーへの対処
第7章 HTTPメソッド
HTTPメソッド一覧
メソッド | 意味 |
---|---|
GET | リソースの取得 |
POST | 子リソースの作成、リソースへのデータの追加、その他の処理 |
PUT | リソースの更新、リソースの作成 |
DELETE | リソースの削除 |
HEAD | リソースのヘッダ(メタデータ)の取得 |
OPTIONS | リソースがサポートしているメソッドの取得 |
TRACE | 自分宛にリクエストメッセージを返す(ループバック)試験 |
CONNECT | プロキシ動作のトンネル接続への変更 |
HTTPメソッドとCRUD
GET,POST,PUT,DELETEはこれら4つで「CRUD」という性質を持つ
Create(作成),Read(読み込み),Update(更新),Delete(削除)というデータ操作の基本の4つ
GET(リソースの取得)
Webページの取得、画像の取得、映像の取得、フィードの取得など
POST(リソースの作成、追加)
ブログ記事の投稿など
リソースへのデータの追加
他のメソッドでは対応できない処理(GETでは処理できない長い検索キーワードでの検索など)
PUT(リソースの更新、作成)
POSTとPUTの使い分け
POSTでリソースを作成する場合、クライアントはリソースのURIを指定できない
PUTでリソースを作成する場合、リソースのURIはクライアントが決定できる
DELETE(リソースの削除)
一般的にDELETEのレスポンスはボディを持たない。そのためステータスコードは204
HEAD(リソースのヘッダの取得)
HEADとGETは似ているが、HEADはリソースのヘッダ(メタデータ)だけを取得する
冪(べき)等性と安全性
べき等とは、ある操作を何回行っても結果が同じこと
安全とは、操作対象のリソースの状態を変化させないこと
GETもHEADもベキ等、その上安全
第8章 ステータスコード
よく使われるステータスコード
- 200 ok (リクエスト成功)
- 201 Created (リソースの作成成功)
- 301 Moved Permanently (リソースの恒久的な移動)
リクエストで指定したリソースが新しいURIに移動したことを示す。 - 303 See Other (別URIの参照)
リクエストに対する処理結果が別のURIで取得できることを示す。 - 400 Bad Request (リクエストの間違い)
リクエストの構文やパラメータが間違っていたことを示す。 - 401 Unauthorized (アクセス権不正)
適切な認証情報を与えずにリクエストを行なったことを示す。 - 404 Nout Found (リソースの不在)
指定したリソースが見つからないことを示す。 - 500 Internal Server Error (サーバ内部エラー)
サーバ側に何らかの異常が生じていて、正しいレスポンスが返せないことを示す。 - 503 Service Unavaliable (サービス停止)
サーバがメンテナンスなどで一時的にアクセスできないことを示す。
ステータスコードとエラー処理
- プロトコルに従ったフォーマットでエラーを返す
- Acceptヘッダに応じたフォーマットでエラーを返す
ステータスコードの誤用
適切なステータスコードを返さないと検索エンジンのロボットが勘違いする
ステータスコードを意識して設計する
第9章 HTTPヘッダ
HTTPヘッダの重要性
ヘッダは、メッセージのボディに対する付加的な情報、いわゆるメタデータを表現する
HTTPヘッダの生い立ち
HTTPで転送する本文のメタデータを表現するために電子メールのメッセージ仕様のヘッダ形式を借りてきた
MIMEメディアタイプ
メッセージでやり取りするリソースの表現の種類を指定するのがMIMEメディアタイプ
- Content-Type メディアタイプをしているす
Content-Typeヘッダは、そのメッセージのボディの内容がどのような種類なのかをメディアタイプで示します。
タイプ | 意味 | 例 |
---|---|---|
text | 人が呼んで直接理解できるテキスト | text/plain |
image | 画像データ | image/jpeg |
audio | 音声データ | audio/mpeg |
video | 映像データ | video/mp4 |
application | その他のデータ | application/pdf |
multipart | 複数のデータからなる複合データ | multipart/related |
message | 電子メールメッセージ | message/rfc822 |
model | 複数次元で構成するモデルデータ | model/vml |
example | 例示用 | example/foo-bar |
charsetパラメータ (文字エンコーディングを指定する)
メディアタイプはcharsetパラメータを持てます。
言語タグ
charsetパラメータは文字エンコーディング方式を指定するものでしたが。リソース表現の自然言語を指定するヘッダも存在する。それがContent-Languageヘッダです。
コンテンツネゴシエーション
- Accept 処理できるメディアタイプを伝える
- Accept-Charset 処理できる文字エンコードディングを伝える
- Accept-Language 処理できる言語を伝える
認証
現在主流のHTTP認証方式には、HTTP1.1が規定しているBasic認証とDigest認証がある。
-
Basic認証
ユーザ名とパスワードによる認証方式。ユーザ名とパスワードはAuthorizationヘッダに入れてリクエストごとの送信する -
Digest認証
Basic認証よりもセキュアな認証方式、ダイジェストとはメッセージダイジェストの略で、あるメッセージに対してハッシュ関数を適用した結果のハッシュ値のこと
コラム
HTTPSは、HTTPとSSL/TLSを組み合わせた通信の総称。通信路を暗号化してクライアントとサーバの間でやり取りするデータを保護し、盗聴を防ぐ目的で主に利用する。
- 暗号化
共通鍵暗号に基づく暗号化機能 - 認証
公開鍵証明書に基づく認証機能 - 改ざん検知
ハッシュ用共通鍵に基づく改ざん検知機能
Digest認証の利点
- Digest認証ではパスワードを盗まれる危険性はない
- パスワードそのものをサーバに預けなくても良い
欠点
- リクエストのたびに一度401 Unauthorizedレスポンスを得なければならない
- ホスティングサービスではサポートしていない可能性もある
WSSE認証
HTTP1.1の標準外の認証方式
OpenIDとOAuth
-
OpenID シンプルなシングルサインオン
OpenIDは、シンプルなシングルサインオンを実現する仕様。OpenIDを使うと、例えばyahoo!のアカウントで自作のWebサービスにログインできる
OpenIDでは、yahoo!やmixiのような、そのWebサービスのアカウントを他のWebサービスにも提供する側のことをIdentity Provider(IdP)と呼び、IdPのアカウントを利用して独自のWebサービスを提供する側のことをService Provider(SP)と呼ぶ。OpenIDを用いると、ユーザはIdPに持っている自分のアカウントでSPにログインできるようになる。 -
OAuth Webサービス間での認可の委譲
OAuthはWebサービス間でのデータをやり取りできるようにするための仕様、先の例で言えば写真を管理し提供する側をService Provider、写真を受け取って印刷する側をConsumerと呼ぶ。ユーザがService ProviderからConsumerにデータを渡すことに同意すると、Service ProviderとConsumerはデータをやり取りする。この機能を「認可情報を委譲する機能」と呼ぶ。
キャッシュ
サーバから取得したリソースをローカルストレージ(ハードディスクなど)に蓄積し、再利用する手法のこと
キャッシュ用ヘッダ
- Pragma キャッシュを抑制する
- Expires キャッシュの有効期限を示す
- Cache-Control 詳細なキャッシュ方法を指定する
第10章 HTML
HTMLとは
Hypertext Markup Languageの略、マークアップ言語とはタグで文書の構造を表現するコンピュータ言語。マークアップ言語でマークアップした構造を持った文書のことを「構造化文書」という
XMLの基礎知識
-
XMLの木構造
XML文書は木構造として表現できる -
要素
XMLは要素で文書の構造を表現する。要素は開始タグ、内容、終了タグから成る。タグには要素名が入り
開始タグは<要素名>
終了タグは要素名>
と記述する -
要素の木構造
XMLの木構造は要素を入れ子にして表現する。 -
空要素
内容を持たない要素のこと<br></br>
終了タグを省略もできる<br/>
第4部 ハイパーメディアフォーマット
第11章 microformats
シンプルなセマンティックWeb
microformatは、セマンティックWebを地に足のついた方向へと導く
RDFとmicroformat
RDF
プログラミングで処理可能な情報の意味を記述する仕様として登場、しかし以下の問題点で普及せず
- 記述が複雑になりがち
- 統一的な記述がしづらい
- 対象データとは独立したメタデータが必要
microformats
元のHTML文書の要素に必要最低限の情報を追加する
RDFと比較すると
- 記述量が減る
- RDFは対象データとは別の独立したメタデータとして記述しなければならないが、microformatsは元のHTMLに埋め込まれている。
- 記述方法のブレがない
microformatsには2種類ある
-
elemental microformat
rel-licenseのように、リンク関係(<a>
要素や<link>
要素のrel属性)を使ってメタデータを表現するフォーマット
rel-license ライセンス情報...Webページのライセンスを記述するためのmicroformats
rel-nofollow スパムリンク防止...Googleなどの検索エンジンは参照リンク数を検索順位の重み付けに利用するため、スパム行為を解決するためのもの -
compound microformats
hCalendarのように、主にclass属性を使って階層構造のあるメタデータを表現するフォーマット
hCalendar イベント情報...カレンダー情報、イベント情報を記述するためのmicroformats
hAtom 更新情報...Atomが持つメタデータをHTMLに埋め込むmicroformats
microformatsとRDFa
-
microformatsの問題点
class属性やrel属性の値だけでメタデータを特定するため、もしたまたま同じ値のclass属性やrel属性を持ったwebページがあった場合、プログラムが誤判定を起こしたり、同じ属性値を持った別のmicroformatsが作れなくなったりする -
RDFaでの解決(と問題点)
RDFaはmicroformatsと見た目はほぼ同じだが、名前の衝突問題をXMLの名前空間で解決する
問題点は、複雑になってしまうのとXHTMLでしか利用できない
第12章 Atom
AtomとはRFC4287が規定するXMLフォーマット
リソースモデルは
メンバリソースとコレクションリソース
第14章 JSON
JSONとは、JavaScript Object Notationの略、JavaScriptの記法でデータを記述できる、拡張子は.json
データ型は
- オブジェクト
- 配列
- 文字列
- 数値
- ブーリアン
- null
第5部
第15章 読み取り専用のWebサービスの設計
リソース設計とは、クライアントとサーバの間のインタフェースの設計。WebサービスやWebAPIの外部設計
リソース設計は
1.Webサービスで提供するデータを特定する
2.データをリソースに分ける
3.リソースにURIで名前をつける
4.クライアントに提供するリソースの表現を設計する
5.リンクとフォームを利用してリソース同士を結びつける
6.イベントの標準的なコースを検討する
7.エラーについて検討する
終わりに
買ってからかなり経ってしまっているものなので最初のwebで使われている汎用的なものに対しては糧になりそうだけど、後ろの方はどうなんだろうか。。。
とりあえずwebで使われている技術についてあらかた復習できたかと思う。
参考
Webを支える技術 - HTTP、URI、HTML、そしてREST -