書籍概要

WEB+DB PRESS plus

Webを支える技術
―― HTTP、URI、HTML、そしてREST

著者
発売日
更新日

概要

Webは誕生から20年で爆発的な普及を果たし，17億人のユーザと2億台のサーバを抱える巨大システムへと成長しました。Webがここまで成功した秘密は，その設計思想，いわゆるアーキテクチャにあります。Webのアーキテクチャ，そしてHTTP，URI，HTMLといったWebを支える技術は，Webがどんなに巨大化しても対応できるように設計されていたのです。

私たちが作る個々のWebサービスも，Webのアーキテクチャにのっとることで成功へとつながります。Webのアーキテクチャに正しく適応したWebサービスは，情報が整理され，ユーザの使い勝手が向上し，ほかのサービスと連携しやすくなり，将来的な拡張性が確保されるからです。

本書のテーマは，Webサービスの実践的な設計です。まずHTTPやURI，HTMLなどの仕様を歴史や設計思想を織り交ぜて解説します。そしてWebサービスにおける設計課題，たとえば望ましいURI，HTTPメソッドの使い分け，クライアントとサーバの役割分担，設計プロセスなどについて，現時点のベストプラクティスを紹介します。

こんな方におすすめ

  • Webサービス（Webアプリケーション／Web API）の設計・開発に携わる方
  • Webのしくみや動作原理を知りたい方
  • URIの仕様や，良いURIについて知りたい方
  • HTTPメソッド，ヘッダ，ステータスコードの仕様や使い方を学びたい方
  • RESTについて学びたい方

本書に関するお知らせ

本書の公式タグは『webtechbook』です。

目次

第1部　Web概論

第1章　Webとは何か

  • 1.1　すべての基盤であるWeb
  • 1.2　さまざまなWebの用途
    • Webサイト
    • ユーザインタフェースとしてのWeb
    • プログラム用APIとしてのWeb
  • 1.3　Webを支える技術
    • HTTP，URI，HTML
    • ハイパーメディア
    • 分散システム
  • 1.4　本書の構成

第2章　Webの歴史

  • 2.1　Web以前のインターネット
  • 2.2　Web以前のハイパーメディア
    • Memex ── ハイパーメディアの起源
    • Xanadu ── 「ハイパーメディア」という言葉の誕生
    • HyperCard ── 初の実用的なハイパーメディア
    • Web以前のハイパーメディアの問題点
  • 2.3　Web以前の分散システム
    • 集中システムと分散システム
    • RPC ── ほかのコンピュータの機能を利用
    • CORBA，DCOM ── 分散オブジェクトへの進化
    • Web以前の分散システムの問題点
  • 2.4　Webの誕生
    • ハイパーメディアとしてのWeb
    • 分散システムとしてのWeb
  • 2.5　Webの標準化
    • Webの仕様策定
    • RESTの誕生
    • さまざまなハイパーメディアフォーマットの誕生
  • 2.6　Web APIをめぐる議論
    • SOAPとWS-*
    • SOAP対REST
    • RESTの誤解と普及
    • SOAPとWS-*の敗因
  • 2.7　すべてがWebへ

第3章　REST ── Webのアーキテクチャスタイル

  • 3.1　アーキテクチャスタイルの重要性
  • 3.2　アーキテクチャスタイルとしてのREST
  • 3.3　リソース
    • リソースの名前としてのURI
    • リソースのアドレス可能性
    • 複数のURIを持つリソース
    • リソースの表現と状態
  • 3.4　スタイルを組み合わせてRESTを構成する
    • クライアント／サーバ
    • ステートレスサーバ
    • キャッシュ
    • 統一インタフェース
    • 階層化システム
    • コードオンデマンド
    • REST = ULCODC$SS
  • 3.5　RESTの2つの側面
    • RESTとハイパーメディア
    • RESTと分散システム
  • 3.6　RESTの意義

第2部　URI

第4章　URIの仕様

  • 4.1　URIの重要性
  • 4.2　URIの構文
    • 簡単なURIの例
    • 複雑なURIの例
  • 4.3　絶対URIと相対URI
    • ベースURI
    • リソースのURIをベースURIとする方法
    • ベースURIを明示的に指定する方法
  • 4.4　URIと文字
    • URIで使用できる文字
    • %エンコーディング
    • %エンコーディングの文字エンコーディング
  • 4.5　URIの長さ制限
  • 4.6　さまざまなスキーム
  • 4.7　URIの実装で気をつけること

第5章　URIの設計

  • 5.1　クールなURIは変わらない
  • 5.2　URIを変わりにくくするためには
    • プログラミング言語に依存した拡張子やパスを含めない
    • メソッド名やセッションIDを含めない
    • URIはリソースを表現する名詞にする
    • URIの設計指針
  • 5.3　URIのユーザビリティ
  • 5.4　URIを変更したいとき
  • 5.5　URI設計のテクニック
    • 拡張子で表現を指定する
    • マトリクスURI
  • 5.6　URIの不透明性
  • 5.7　URIを強く意識する

第3部　HTTP

第6章　HTTPの基本

  • 6.1　HTTPの重要性
  • 6.2　TCP/IPとは何か
    • 階層型プロトコル
    • ネットワークインタフェース層
    • インターネット層
    • トランスポート層
    • アプリケーション層
  • 6.3　HTTPのバージョン
    • HTTP 0.9 ── HTTPの誕生
    • HTTP 1.0 ── HTTP最初の標準化
    • HTTP 1.1 ── HTTPの完成
    • その後のHTTP
  • 6.4　クライアントとサーバ
  • 6.5　リクエストとレスポンス
    • クライアントで行われること
    • サーバで行われること
  • 6.6　HTTPメッセージ
    • リクエストメッセージ
    • レスポンスメッセージ
    • HTTPメッセージの構成要素
  • 6.7　HTTPのステートレス性
    • ハンバーガーショップの例
    • アプリケーション状態
    • ステートフルの欠点
    • ステートレスの利点
    • ステートレスの欠点
  • 6.8　シンプルなプロトコルであることの強み

第7章　HTTPメソッド

  • 7.1　8つしかないメソッド
  • 7.2　HTTPメソッドとCRUD
  • 7.3　GET ── リソースの取得
  • 7.4　POST ── リソースの作成，追加
    • 子リソースの作成
    • リソースへのデータの追加
    • ほかのメソッドでは対応できない処理
  • 7.5　PUT ── リソースの更新，作成
    • リソースの更新
    • リソースの作成
    • POSTとPUTの使い分け
  • 7.6　DELETE ── リソースの削除
  • 7.7　HEAD ── リソースのヘッダの取得
  • 7.8　OPTIONS ── リソースがサポートしているメソッドの取得
  • 7.9　POSTでPUT/DELETEを代用する方法
    • _methodパラメータ
    • X-HTTP-Method-Override
  • 7.10　条件付きリクエスト
  • 7.11　べき等性と安全性
    • PUTはべき等
    • DELETEもべき等
    • GETとHEADもべき等，そのうえ安全
    • 安全でもべき等でもないPOST
  • 7.12　メソッドの誤用
    • GETが安全でなくなる例
    • ほかのメソッドでできることにPOSTを誤用した例
    • PUTがべき等でなくなる例
    • DELETEがべき等でなくなる例
  • 7.13　Webの成功理由はHTTPメソッドにあり

第8章　ステータスコード

  • 8.1　ステータスコードの重要性
  • 8.2　ステータスラインのおさらい
  • 8.3　ステータスコードの分類と意味
  • 8.4　よく使われるステータスコード
    • 200 OK ── リクエスト成功
    • 201 Created ── リソースの作成成功
    • 301 Moved Permanently ── リソースの恒久的な移動
    • 303 See Other ── 別URIの参照
    • 400 Bad Request ── リクエストの間違い
    • 401 Unauthorized ── アクセス権不正
    • 404 Not Found ── リソースの不在
    • 500 Internal Server Error ── サーバ内部エラー
    • 503 Service Unavailable ── サービス停止
  • 8.5　ステータスコードとエラー処理
    • プロトコルに従ったフォーマットでエラーを返す
    • Acceptヘッダに応じたフォーマットでエラーを返す
  • 8.6　ステータスコードの誤用
  • 8.7　ステータスコードを意識して設計する

第9章　HTTPヘッダ

  • 9.1　HTTPヘッダの重要性
  • 9.2　HTTPヘッダの生い立ち
  • 9.3　日時
  • 9.4　MIMEメディアタイプ
    • Content-Type ── メディアタイプを指定する
    • charsetパラメータ ── 文字エンコーディングを指定する
  • 9.5　言語タグ
  • 9.6　コンテントネゴシエーション
    • Accept ── 処理できるメディアタイプを伝える
    • Accept-Charset ── 処理できる文字エンコーディングを伝える
    • Accept-Language ── 処理できる言語を伝える
  • 9.7　Content-Lengthとチャンク転送
    • Content-Length ── ボディの長さを指定する
    • チャンク転送 ── ボディを分割して転送する
  • 9.8　認証
    • Basic認証
    • Digest認証
    • WSSE認証
  • 9.9　キャッシュ
    • キャッシュ用ヘッダ
    • 条件付きGET
  • 9.10　持続的接続
  • 9.11　そのほかのHTTPヘッダ
    • Content-Disposition ── ファイル名を指定する
    • Slug ── ファイル名のヒントを指定する
  • 9.12　HTTPヘッダを活用するために

第4部　ハイパーメディアフォーマット

第10章　HTML

  • 10.1　HTMLとは何か
  • 10.2　メディアタイプ
  • 10.3　拡張子
  • 10.4　XMLの基礎知識
    • XMLの木構造
    • 要素
    • 属性
    • 実体参照と文字参照
    • コメント
    • XML宣言
    • 名前空間
  • 10.5　HTMLの構成要素
    • ヘッダ
    • ボディ
    • 共通の属性
  • 10.6　リンク
    • <a>>要素 ── アンカー
    • <link>要素
    • オブジェクトの埋め込み
    • フォーム
  • 10.7　リンク関係 ── リンクの意味を指定する
    • rel属性
    • microformats
  • 10.8　ハイパーメディアフォーマットとしてのHTML

第11章　microformats

  • 11.1　シンプルなセマンティックWeb
  • 11.2　セマンティクス（意味論）とは
    • 言語学における意味論
    • プログラミング言語における意味論
    • Webにおける意味論
  • 11.3　RDFとmicroformats
    • RDFの場合
    • microformatsの場合
  • 11.4　microformatsの標準化
  • 11.5　microformatsの分類
    • elemental microformats
    • compound microformats
  • 11.6　microformatsとRDFa
    • microformatsの問題点
    • RDFaでの解決（と残る問題点）
  • 11.7　microformatsの可能性
    • Tim Brayの疑問
    • hAtom/xFolkとLDRize/AutoPagerize
  • 11.8　リソースの表現としてのmicroformats

第12章　Atom

  • 12.1　Atomとは何か
  • 12.2　Atomのリソースモデル
    • メンバリソース
    • コレクションリソース
    • メディアタイプ
    • 拡張子
    • 名前空間
  • 12.3　エントリ ── Atomの最小単位
    • メタデータ
    • エントリの内容
  • 12.4　フィード ── エントリの集合
    • エントリと共通のメタデータ
    • フィード独自のメタデータ
  • 12.5　Atomの拡張
    • Atom Threading Extensions ── スレッドを表現する
    • Atom License Extension ── ライセンス情報を表現する
    • Feed Paging and Archiving ── フィードを分割する
    • OpenSearch ── 検索結果を表現する
  • 12.6　Atomを活用する

第13章　Atom Publishing Protocol

  • 13.1　Atom Publishing Protocolとは何か
    • AtomとAtomPub
    • AtomPubの意義
    • AtomPubとREST
  • 13.2　AtomPubのリソースモデル
  • 13.3　ブログサービスを例に
  • 13.4　メンバリソースの操作
    • エントリ単位での操作
    • メディアリソースの操作
  • 13.5　サービス文書
    • メディアタイプ
    • <service>要素
    • <workspace>要素
    • <accept>要素
    • カテゴリ
  • 13.6　AtomPubに向いているWeb API

第14章　JSON

  • 14.1　JSONとは何か
  • 14.2　メディアタイプ
  • 14.3　拡張子
  • 14.4　データ型
    • オブジェクト
    • 配列
    • 文字列
    • 数値
    • ブーリアン
    • null
    • 日時
    • リンク
  • 14.5　JSONPによるクロスドメイン通信
    • クロスドメイン通信の制限
    • <script>要素による解決
    • コールバック関数を活用するJSONP
  • 14.6　ハイパーメディアフォーマットとしてのJSON

第5部　Webサービスの設計

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

  • 15.1　リソース設計とは何か
  • 15.2　リソース指向アーキテクチャのアプローチ
  • 15.3　郵便番号検索サービスの設計
  • 15.4　Webサービスで提供するデータを特定する
  • 15.5　データをリソースに分ける
  • 15.6　リソースにURIで名前を付ける
    • 郵便番号リソース
    • 検索結果リソース
    • 地域リソース
    • トップレベルリソース
  • 15.7　クライアントに提供するリソースの表現を設計する
    • XML表現
    • 軽量フォーマット表現
    • URIで表現を指定する
  • 15.8　リンクとフォームを利用してリソース同士を結び付ける
    • 検索結果リソース
    • 地域リソース
    • 郵便番号リソース
    • トップレベルリソース
    • リソース間のリンク関係
  • 15.9　イベントの標準的なコースを検討する
  • 15.10　エラーについて検討する
    • 存在しないURIを指定した
    • 必須パラメータを指定していない
    • サポートしないメソッドを使用した
  • 15.11　リソース設計のスキル

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

  • 16.1　書き込み可能なWebサービスの難しさ
  • 16.2　書き込み可能な郵便番号サービスの設計
  • 16.3　リソースの作成
    • ファクトリリソースによる作成
    • PUTによる作成
  • 16.4　リソースの更新
    • バルクアップデート
    • パーシャルアップデート
    • 更新できないプロパティを更新しようとした場合
  • 16.5　リソースの削除
  • 16.6　バッチ処理
    • バッチ処理のリクエスト
    • バッチ処理のレスポンス
  • 16.7　トランザクション
    • 解決すべき問題
    • トランザクションリソース
    • トランザクションリソース以外の解決方法
  • 16.8　排他制御
    • 解決すべき問題
    • 悲観的ロック
    • 楽観的ロック
  • 16.9　設計のバランス

第17章　リソースの設計

  • 17.1　リソース指向アーキテクチャのアプローチの落とし穴
  • 17.2　関係モデルからの導出
    • 郵便番号データのER図
    • 中心となるテーブルからのリソースの導出
    • リソースが持つデータの特定
    • 検索結果リソースの導出
    • 階層の検討
    • トップレベルリソース
    • リンクによる結合
    • まとめ
  • 17.3　オブジェクト指向モデルからの導出
    • 郵便番号データのクラス図
    • 主要データクラスからのリソースの導出
    • オブジェクトの操作結果リソース
    • 階層の検討
    • トップレベルリソース
    • リンクによる結合
    • まとめ
  • 17.4　情報アーキテクチャからの導出
    • 日本郵便のWebサイトの情報アーキテクチャ
    • トップページ
    • 全国地図からの検索
    • 住所での検索
    • 郵便番号での検索
    • パンくずリスト
    • まとめ
  • 17.5　リソース設計で最も重要なこと

付録

付録A　ステータスコード一覧

  • A.1　1xx（処理中）
    • 100 Continue
    • 101 Switching Protocols
  • A.2　2xx（成功）
    • 200 OK
    • 201 Created
    • 202 Accepted
    • 203 Non-Authoritative Information
    • 204 No Content
    • 205 Reset Content
    • 206 Partial Content
    • 207 Multi-Status
  • A.3　3xx（リダイレクト）
    • 300 Multiple Choices
    • 301 Moved Permanently
    • 302 Found
    • 303 See Other
    • 304 Not Modified
    • 305 Use Proxy
    • 307 Temporary Redirected
  • A.4　4xx（クライアントエラー）
    • 400 Bad Request
    • 401 Unauthorized
    • 402 Payment Required
    • 403 Forbidden
    • 404 Not Found
    • 405 Method Not Allowed
    • 406 Not Acceptable
    • 407 Proxy Authentication Required
    • 408 Request Timeout
    • 409 Conflict
    • 410 Gone
    • 411 Length Required
    • 412 Precondition Failed
    • 413 Request Entity Too Large
    • 414 Request-URI Too Long
    • 415 Unsupported Media Type
    • 416 Requested Range Not Satisfiable
    • 417 Expectation Failed
    • 422 Unprocessable Entity
    • 423 Locked
    • 424 Failed Dependency
  • A.5　5xx（サーバエラー）
    • 500 Internal Server Error
    • 501 Not Implemented
    • 502 Bad Gateway
    • 503 Service Unavailable
    • 504 Gateway Timeout
    • 505 HTTP Version Not Supported

付録B　HTTPヘッダ一覧

  • B.1　サーバ情報
    • Date
    • Retry-After
    • Server
    • Set-Cookie
  • B.2　クライアント情報
    • Cookie
    • Expect
    • From
    • Referer
    • User-Agent
  • B.3　リソース情報
    • Content-Encoding
    • Content-Language
    • Content-Length
    • Content-MD5
    • Content-Type
    • Content-Location
    • Last-Modified
    • Location
    • Host
  • B.4　コンテントネゴシエーション
    • Accept
    • Accept-Charset
    • Accept-Encoding
    • Accept-Language
    • Vary
  • B.5　条件付きリクエスト
    • ETag
    • If-None-Match
    • If-Modified-Since
    • If-Match
    • If-Unmodified-Since
  • B.6　部分的GET
    • Range
    • If-Range
    • Accept-Range
    • Content-Range
  • B.7　キャッシュ
    • Pragma
    • Cache-Control
    • Expires
    • Age
  • B.8　認証
    • WWW-Authenticate
    • Authorization
    • Proxy-Authenticate
    • Proxy-Authorization
    • X-WSSE
  • B.9　チャンク転送
    • Transfer-Encoding
    • Trailer
    • TE
  • B.10　そのほか
    • Allow
    • Connection
    • Max-Forwards
    • Upgrade
    • Via
    • Warning
    • Content-Disposition
    • Slug
    • X-HTTP-Override

付録C　解説付き参考文献

サポート

正誤表

本書の以下の部分に誤りがありました。ここに訂正するとともに，ご迷惑をおかけしたことを深くお詫び申し上げます。

（2021年4月28日最終更新）

以下，第1刷から第15刷まで。
第16刷以降では修正済み

P.145　下から7行目

誤
Cache-Control: max-age: 86400
正
Cache-Control: max-age=86400

P.348　「Cache-Control」の3行目

誤 max-age: xxxxx
正 max-age=xxxxx

（以下2020年6月17日更新）

以下，第1刷から第13刷まで。
第14刷以降および最新の電子版では修正済み

P.109　5行目

誤 しかし、/latestというエイリアスリソースではく、
正しかし、/latestというエイリアスリソースではなく

（以下2019年4月16日更新）

以下，第1刷から第11刷まで。

P.161　7行目

誤 http://www.w3.org/1995/Atom
正 http://www.w3.org/2005/Atom

（以下2019年8月23日更新）

以下，第1刷から第8刷まで。
第9刷以降および最新の電子版では修正済み

P.165　表10.4

誤 sub上付き文字
sup下付き文字
正 sup上付き文字
sub下付き文字

P.24　下から8行目

誤 1台のPCにインストールできるだけのデータしか扱えせん。
正 1台のPCにインストールできるだけのデータしか扱えません。

P.127　注2

誤 メールプトロコル
正 メールプロトコル

P.139

誤 メソッドとURIのパスを「:」で連結し。MD5ハッシュ値を求める
正 メソッドとURIのパスを「:」で連結し、MD5ハッシュ値を求める

P.165

誤 画像埋め込みなど表現します。
正 画像埋め込みなどを表現します。

以下，第1刷から第6刷まで。
第7刷以降および最新の電子版では修正済み

P.77　本文の下から4行目

誤 

GET http://example.jp/test HTTP/1.1
リクエストURIにパスを用いた場合はHostヘッダが必須ですが、絶対URIを用いた場合はHostヘッダを省略できます。HTTP1.1の場合はリクエストURIの形式はどちらでもかまわないのですが（注7）、本書では紙幅を節約するため相対URIを用います。
正 

GET http://example.jp/test HTTP/1.1
Host: example.jp
Hostヘッダは必須です。HTTP1.1の場合はリクエストURIの形式はパスでも絶対URIでもかまわないのですが（注7）、本書では紙幅を節約するためパスを用います。

以下，第1刷から第5刷まで。
第6刷以降および最新の電子版では修正済み

P.155の3行目，およびP.365の右段1行目

誤 <navi>要素
正 <nav>要素

以下，第1刷と第2刷のみ。
第3刷以降および最新の電子版では修正済み/h4>

P.19　「RESTの誕生」の4行目

誤 Webの創世記
正 Webの創成期

P.77　13行目

誤 

GET /search?q=test&debug=true#n10 HTTP/1.1
正 

GET /search?q=test&debug=true HTTP/1.1

P.77　15行目

誤 リクエストラインにはパス以降の文字列が入ります。
正 リクエストラインにはURIフラグメントを除いたパス以降の文字列が入ります。URIフラグメントはクライアント側で処理するのでリクエストメッセージには含めません。

P.99　「_methodパラメータ」の7行目

誤 

<input type="hidden" id="_method" value="PUT">
正 

<input type="hidden" id="_method" name="_method" value="PUT"/>

P.164　9行目

誤 

<input type="text" id="q"/>
<input type="submit" value="検索"/>
正 

<input type="text" id="q" name="q"/>
<input type="submit" id="submit" name="submit" value="検索"/>

P.169　下から4行目

誤 

<input type="text" id="q"/>
<input type="submit" value="検索"/>
正 

<input type="text" id="q" name="q"/>
<input type="submit" id="submit" name="submit" value="検索"/>

P.171　10行目

誤 

<p>題名:<input type="text" id="title"/><br/>
   著者:<input type="text" id="author"/><br/>
  <input type="submit" value="検索"/></p>
正 

<p>題名:<input type="text" id="title" name="title"/><br/>
   著者:<input type="text" id="author" name="author"/><br/>
  <input type="submit" id="submit" name="submit"</p>

P.202　下から7行目

誤 

ref="tag:example.org,2010:1"
正 

ref="tag:bbs.example.jp,2010:1"

P.221　3行目

誤 特に、クライアントが送信している<update>要素が、取得してきた時刻と同じであることに注意してください。<update>要素や
正 特に、クライアントが送信している<updated>要素が、取得してきた時刻と同じであることに注意してください。<updated>要素や

P.211　6行目

誤 

<link rel="next-archive" href="http://blog.example.org/201009.atom"/>
<link rel="prev-archive" href="http://blog.example.org/201007.atom"/>
<link href="http://example.org/201008/32"/>
正 

<link rel="next-archive" href="http://blog.example.jp/201009.atom"/>
<link rel="prev-archive" href="http://blog.example.jp/201007.atom"/>
<link href="http://example.jp/201008/32"/>

P.260　13行目

誤 

<p><a href="http://zip.ricollab.jp/search?q=112&page=2"
正 

<p><a href="http://zip.ricollab.jp/search?q=112&amp;page=2"

P.264　下から10行目

誤 

<input id="q" type="text"/>
<input type="radio" name="type" value="json"> JSON,
<input type="radio" name="type" value="html"> XHTML
<input type="submit" value="検索"/>
正 

<input id="q" name="q" type="text"/>
<input type="radio" id="type1" name="type" value="json"/> JSON,
<input type="radio" id="type2" name="type" value="html"/> XHTML
<input type="submit" id="submit" name="submit" value="検索"/>

以下，第1刷のみ。
第2刷以降および最新の電子版では修正済み

P.88　表7.1の下から2行目

誤 プロキシ動作の確認
正 自分宛にリクエストメッセージを返す（ループバック）試験

P.98 「POSTでPUT/DELETEを代用する方法」の6行目

誤 

<form action="GET" target="/list">
正 

<form method="GET" action="/list">

P.98 「POSTでPUT/DELETEを代用する方法」の10行目

誤 

<form action="POST" target="/list">
正 

<form method="POST" action="/list">

P.99　「_methodパラメータ」の6行目

誤 

<form target="/list/item1" action="post">
正 

<form method="POST" action="/list/item1">

P.132　本文の下から4行目

誤 この例の場合、text/html、application/xhtml+xml、application/xmlの３つが0.9という優先度で、それ以外のすべてのメディアタイプ（*/*）が0.8という優先度です。
正 この例の場合、text/html、application/xhtml+xmlがデフォルトの1、application/xmlが0.9、それ以外のすべてのメディアタイプ（*/*）が0.8という優先度です。

P.133　「Accept-Charset ── 処理できる文字エンコーディングを伝える」の3行目

誤 

Accept-Charset: Shift_JIS;utf-8;q=0.7,*;q=0.7
　この例ではShift_JISとUTF-8およびそれ以外のすべてのエンコーディング方式が優先度0.7で並んでいますが、Shift_JISとUTF-8のほうがより具体的であるため、こちらの2つを優先します。
正 

Accept-Charset: Shift_JIS,utf-8;q=0.7,*;q=0.7
　この例ではShift_JISと、Accept-Charsetヘッダのデフォルト文字エンコーディングISO8859-1がqvalueのデフォルト値である優先度1になりますが、より具体的なShift_JISを優先します。これらに続いて、UTF-8およびそれ以外のすべてのエンコーディング方式が0.7の優先度となります。

P.133　下から2行目

誤 この例では日本語（ja）とアメリカ英語（en-us）が優先度0.7で、地域を特に指定しない英語（en）が優先度0.3で続きます。
正 この例では日本語（ja）がデフォルトの1、アメリカ英語（en-us）が0.7、地域を特に指定しない英語（en）が0.3という優先度です。

P.169　下から6行目

誤 

<form target="http://example.jp/search" action="GET">
正 

<form method="GET" action="http://example.jp/search">

P.170　7行目

誤 ターゲットURIは<form>要素のtarget属性で指定します。
正 ターゲットURIは<form>要素のaction属性で指定します。

P.170　10行目

誤 そのときに用いるメソッドは<form>要素のaction属性で指定します。
正 そのときに用いるメソッドは<form>要素のmethod属性で指定します。

P.170　13行目

誤 action属性の値がGETの場合、
正 method属性の値がGETの場合、

P.171　4行目

誤 action属性の値がPOSTの例を見てみましょう。
正 method属性の値がPOSTの例を見てみましょう。

P.171　9行目

誤 

<form target="http://example.jp/article" action="POST">
正 

<form method="POST" action="http://example.jp/article">

P.171　16行目

誤 action属性がPOSTの場合、
正 method属性がPOSTの場合、

P.209　最下行

誤 ※fistとlastは、RFC 5005ではなく、Atomの仕様策定後にIANAに提案されたリンク関係
正 ※firstとlastは、RFC 5005ではなく、Atomの仕様策定後にIANAに提案されたリンク関係

P.324　11行目

誤 

Allow: GET, POST, HEAD, OPTIONS
正 

Allow: GET, POST, HEAD

商品一覧