1. アーカイブ
1.1. 10章
1.1.1. 岩﨑
1.1.1.1. HTML
1.1.1.1.1. とは
1.1.1.1.2. メディアタイプ
1.1.1.1.3. 文字エンコーディング
1.1.1.1.4. 拡張子
1.1.1.1.5. 構成要素
1.1.2. 江幡
1.1.2.1. HTMLについて
1.1.2.1.1. SGMLとXMLベースがある
1.1.2.1.2. XML
1.1.2.1.3. HTML
1.1.3. 宮本
1.1.3.1. HTML
1.1.3.1.1. メディアタイプ
1.1.3.1.2. 拡張子
1.1.3.1.3. XMLの仕様
1.1.3.1.4. 構成要素
1.1.3.1.5. <a>要素
1.1.3.1.6. <link>要素
1.1.3.1.7. rel属性
1.1.3.1.8. フォーム
1.2. 第1,2章
1.2.1. 宮本
1.2.1.1. Web
1.2.1.1.1. URI
1.2.1.1.2. HTTP
1.2.1.1.3. HTML
1.2.1.1.4. 分散システム
1.2.1.2. Web以前のインターネット
1.2.1.2.1. 英数字
1.2.1.2.2. 遅延
1.2.2. 岩﨑
1.2.2.1. WEB用途
1.2.2.1.1. WEBサイト
1.2.2.1.2. ユーザインターフェース （各種デバイス設定
1.2.2.1.3. プログラム用API
1.2.2.2. WEB技術
1.2.2.2.1. HTTP
1.2.2.2.2. URI
1.2.2.2.3. HTML
1.2.2.3. WEBの歴史
1.2.2.3.1. 1940年台
1.2.2.3.2. 1960年台
1.2.2.3.3. 1970年台
1.2.2.3.4. 1980年台
1.2.2.3.5. 1990年台
1.2.3. 江幡
1.2.3.1. Webのベース思想
1.2.3.1.1. 分散システム
1.2.3.1.2. ハイパーメディア
1.2.3.2. Webのベース技術
1.2.3.2.1. HTML
1.2.3.2.2. HTTP
1.2.3.2.3. URI
1.2.3.2.4. あとから追加された技術
1.2.3.3. Webのいいところ
1.2.3.3.1. シンプルisベスト
1.2.3.4. ブレイクスルー
1.2.3.4.1. Ajax
1.3. 第5章
1.3.1. 岩﨑
1.3.1.1. URIの設計ポイント
1.3.1.1.1. できるだけ変更しない
1.3.1.1.2. シンプルに、覚えやすく
1.3.1.1.3. 変更したいと時はリダイレクト
1.3.1.1.4. 拡張子で言語を表す
1.3.1.1.5. マトリクスURI
1.3.1.1.6. URIの不透明性
1.3.2. 江幡
1.3.2.1. URIの設計
1.3.2.1.1. 悪いURIの設計
1.3.2.1.2. 良い設計
1.3.3. 宮本
1.3.3.1. URIの設計
1.3.3.1.1. 変わりにくくするために
1.3.3.1.2. 変更したいとき
1.3.3.1.3. 設計のテクニック拡張子で表現を指定する
1.3.3.1.4. 不透明性
1.4. 第4章
1.4.1. 岩﨑
1.4.1.1. Uniform Resource Identifier（URI）
1.4.1.1.1. 例：http://blog.example.jp/entries/1:8000
1.4.1.1.2. URI実装上の注意
1.4.2. 江幡
1.4.2.1. URI(Uniform Resorce Identifier :RFC 3986)
1.4.2.1.1. 構成パーツ
1.4.2.1.2. 絶対URIと相対URI
1.4.2.1.3. 文字
1.4.2.1.4. URIの実装はとりあえずこれやっとけ
1.5. 第3章
1.5.1. 岩﨑
1.5.1.1. アーキテクチャスタイル
1.5.1.1.1. ネットワークシステム
1.5.1.2. リソース
1.5.1.2.1. URI
1.5.1.3. REST（REpresentational State Transfer）
1.5.1.3.1. 複合アーキテクチャ
1.5.1.4. REST以外＝SOAP、RPC、GraphQL
1.5.2. 宮本
1.5.2.1. アーキテクチャスタイル
1.5.2.1.1. 複数のコンポーネントの組み合わせ
1.5.2.1.2. 設計の指針・作法
1.5.2.1.3. REST
1.6. 第6章
1.6.1. 岩﨑
1.6.1.1. HTTP
1.6.1.1.1. PCで使えるデータであればなんでも転送可能
1.6.1.1.2. バージョン
1.6.1.1.3. 特徴
1.6.1.1.4. 通信の流れ
1.6.1.1.5. HTTPメッセージ
1.6.1.2. 階層型プロトコル
1.6.1.2.1. アプリケーション層
1.6.1.2.2. トランスポート層
1.6.1.2.3. インターネット層
1.6.1.2.4. ネットワークインターフェース層
1.6.2. 江幡
1.6.2.1. HTTP
1.6.2.1.1. HTTPのベースとなるプロトコル
1.6.2.1.2. HTTPのVersion
1.6.2.1.3. HTTPメッセージの構造
1.6.2.1.4. HTTPの仕組み
1.7. 第7章
1.7.1. 岩﨑
1.7.1.1. HTTPメソッド
1.7.1.1.1. GET
1.7.1.1.2. POST
1.7.1.1.3. PUT
1.7.1.1.4. DELETE
1.7.2. 江幡
1.7.2.1. この世に8つしかないHTTPメソッド
1.7.2.1.1. GET（利用頻度★★★）
1.7.2.1.2. POST★★
1.7.2.1.3. PUT★
1.7.2.1.4. DELETE★
1.7.2.1.5. HEAD
1.7.2.1.6. OPTIONS
1.7.2.1.7. (TRACE)
1.7.2.1.8. （CONNECT)
1.7.2.2. どっちも更新や作成ができるPOSTとPUTメソッドの使い分け
1.7.2.2.1. POST
1.7.2.2.2. PUT
1.7.2.3. POSTでPUT/DELETEを代用する方法
1.7.2.3.1. HTMLフォームではGETとPOSTしか使えない設計なので、結果的によく使われる
1.7.2.4. 条件付きリクエスト
1.7.2.4.1. 日時や更新があったかどうかなどで更新ができるリクエスト
1.7.2.5. べきとうせいと安全性
1.7.2.5.1. べきとうせい
1.7.2.5.2. 安全性
1.7.2.5.3. メソッドによる性質の違い
1.7.2.5.4. ただし、設計によっては安全じゃなくなってしまうのでちゅういしてね、
1.8. 第8章
1.8.1. 岩﨑
1.8.1.1. ステータスコードとは
1.8.1.1.1. HTTPレスポンスメッセージの中で意味を伝えるコード
1.8.1.2. ステータスコード
1.8.1.2.1. 200 OK
1.8.1.2.2. 201 Created
1.8.1.2.3. 301 Moved Permanently
1.8.1.2.4. 303 See Other
1.8.1.2.5. 400 Bad Request
1.8.1.2.6. 401 Unauthorized
1.8.1.2.7. 404 Not Found
1.8.1.2.8. 500 Internal Server Error
1.8.1.2.9. 503 Service Unavailable
1.8.2. 江幡
1.8.2.1. ステータスコード
1.8.2.1.1. 先頭で分類
1.8.2.1.2. 気をつけよう
1.8.3. 宮本
1.8.3.1. ステータスコード
1.8.3.1.1. とは？
1.8.3.1.2. 先頭の数字で分類（100, 200など)
1.8.3.1.3. 代表例
1.8.3.1.4. エラー処理
1.8.3.1.5. 重要性
1.9. 第9章
1.9.1. 岩﨑
1.9.1.1. HTTPヘッダ
1.9.1.1.1. メタデータ
1.9.1.1.2. 用途
1.9.1.1.3. 歴史
1.9.1.1.4. 種類
1.9.2. 宮本
1.9.2.1. HTTPヘッダ
1.9.2.1.1. 重要性
1.9.2.1.2. 主なヘッダの種類
1.9.2.1.3. 認証
1.9.3. 江幡
1.9.3.1. HTTP`ヘッダ
1.9.3.1.1. メッセージのボディに対する付加的な情報（メタデータ）を表す
2. 11章
2.1. 宮本
2.1.1. microformats
2.1.1.1. microformatsとは？
2.1.1.1.1. HTMLの中で、意味のあるデータを表現するための技術
2.1.1.1.2. リンクの細かい意味やイベント情報などを表現できる
2.1.1.1.3. セマンティックWebを地に足のついた方向へ導く
2.1.1.2. RDF
2.1.1.2.1. プログラムで処理可能な情報の意味を記述するためのフレームワーク
2.1.1.2.2. 主語、術後、目的語の3つの組で構成
2.1.1.2.3. 外部ファイルにしたり、XHTML中に埋め込んだりする必要がある
2.1.1.2.4. 問題点
2.1.1.2.5. RDFの問題点を解決したのがmicroformats
2.1.1.3. 分類
2.1.1.3.1. elemental microformats
2.1.1.3.2. compund microformats
2.1.1.4. 問題点
2.1.1.4.1. 試用したclass属性やrel属性と同じ値を持ったWebページがあった場合、プログラムが誤判定を起こしたりする
2.1.1.4.2. RDFaで解決
2.1.1.5. 強味
2.1.1.5.1. プログラム用に別のAPIを提供するスタイルの弱点を補ってくれる
2.1.1.5.2. 既存のWebページをそのままWebAPPIとして提供可能
2.2. 岩﨑
2.2.1. Microformats
2.2.1.1. メタデータをHTMLに埋め込む技術
2.2.1.2. 恐らく現在あまり使われていない
2.2.1.2.1. メタデータはmetaタグでつける
2.2.1.2.2. Microdataという仕様を使う
2.2.1.3. 主な用途
2.2.1.3.1. スパムリンク防止
2.2.1.3.2. Webページのライセンス表記
2.3. 江幡
2.3.1. セマンティック
2.3.1.1. 意味づけ
2.3.1.1.1. Microformatsは使われてないって光が言ってた
2.3.1.1.2. Webサイトのコメント欄とかにURLを載せてもGoogleとかの検索エンジンのランキングには反映されないなどができたらしい。