Contents
  1. 正誤情報の報告方法
  2. 検討中のフィードバック
  3. 増刷時の変更内容(バグフィックス)
    1. 4刷→5刷の差分(2013/9)
    2. 3刷→4刷の差分(2012/4)
    3. 2刷→3刷の差分(2011/01)
    4. 1刷→2刷の差分(2010/04)
    5. 修正しない
  4. 改訂時の変更内容(機能追加)
  5. 各種検索

Webを支える技術サポートWiki

Webを支える技術』の正誤情報などをまとめるWikiです。

正誤情報の報告方法

  • Twitterでハッシュタグ#webtechbookを付けて発言してください
  • @yohei(著者)、@inao(編集者)も付けていただけると確実です
  • このWikiに直接書き込んでいただくのでも大丈夫です(仕様により要ログイン)

検討中のフィードバック

※このWikiに直接報告する場合は、ここに書き込んでください。

  • ページ
    • 報告内容の要約
    • 報告URL
      • 増刷時の対応方法(誤→正 or 変更しない理由)
  • RESTが先か、Webが先か
    • RESTが先と誤読される記述がある
    • http://togetter.com/li/19994
    • 誤読される表現はどこか調査。増刷で対応できるか、改訂規模じゃないと対応できないかを検討。

増刷時の変更内容(バグフィックス)

※増刷時の変更事項です。基本的に、誤字脱字レベルの細部の変更しか行えません。

4刷→5刷の差分(2013/9)

  • 修正なし

3刷→4刷の差分(2012/4)

  • 修正なし

2刷→3刷の差分(2011/01)

  • p.19「RESTの誕生」の4行目
    • 誤字
      • ×:Webの創世記
      • ○:Webの創成期
  • p.77
    • リクエストURIにフラグメントが入っている
    • https://twitter.com/kazuho/status/12483438181
      • ×: サーバ上のリソースに対して行いたい処理を指定します ※間違いではないが、行数調整のため修正
      • ○: サーバ上のリソースに対する処理を指定します
      • ×: GET /search?q=test&debug=true#n10 HTTP/1.1
      • ○: GET /search?q=test&debug=true HTTP/1.1
      • ×: リクエストラインにはパス以降の文字列が入ります。
      • ○: リクエストラインにはURIフラグメントを除いたパス以降の文字列が入ります。URIフラグメントはクライアント側で処理するのでリクエストメッセージには含めません。
  • p.120
    • 前ページの名残で/tsetになっているところが2箇所ある。500の例と503の例
      • 前ページでは/tsetというURIをNot Foundの例として使っています。Not Foundなリソースが500や503になってもよいのですが、意味が伝わりづらくなるので、ここは/tsetではなく/fooにします
      • ×: GET /tset HTTP/1.1
      • ○: GET /foo HTTP/1.1
  • p.164
    • <input>要素にname属性がない
    • http://twitter.com/iwamot/statuses/13552442097
      • ×: <input type="text" id="q"/>
      • ○: <input type="text" id="q" name="q"/>
      • ×: <input type="submit" value="検索"/>
      • ○: <input type="submit" id="submit" name="submit" value="検索"/>
  • p.169
    • <input>要素にname属性がない
    • http://twitter.com/iwamot/statuses/13552442097
      • ×: <input type="text" id="q"/>
      • ○: <input type="text" id="q" name="q"/>
      • ×: <input type="submit" value="検索"/>
      • ○: <input type="submit" id="submit" name="submit" value="検索"/>
  • p.171
    • <input>要素にname属性がない
    • http://twitter.com/iwamot/statuses/13552442097
      • ×: <p>題名:<input type="text" id="title"/><br/>
      • ○: <p>題名:<input type="text" id="title" name="title"/><br/>
      • ×: 著者:<input type="text" id="author"/><br/>
      • ○: 著者:<input type="text" id="author" name="author"/><br/>
      • ×: <input type="submit" value="検索"/></p>
      • ○: <input type="submit" id="submit" name="submit" value="検索"/></p>
  • p.202
    • 子エントリの <thr:in-reply-to> 要素の ref 属性の値と、親エントリの ID の値が一致していない
    • https://twitter.com/fkmn/status/12388507330
      • ×: ref="tag:example.org,2010:1"
      • ○: ref="tag:bbs.example.jp,2010:1"
  • p.221 上から3行目
    • <update>→<updated>(2箇所)
      • ×:特に、クライアントが送信している<update>要素が、取得してきた時刻と同じであることに注意してください。<update>要素や
      • ○:特に、クライアントが送信している<updated>要素が、取得してきた時刻と同じであることに注意してください。<updated>要素や
  • p.256
    • 「JSONの配列の最後のカンマは不要(誤りではない)」な件が他にもあった
    • http://twitter.com/kawanet/status/12216587436
      • 構文的には間違っていないが、ほかの例はすべて入れていないので統一する
      • ×: "address": "東京都文京区以下に掲載がない場合",
      • ○: "address": "東京都文京区以下に掲載がない場合"
      • ×: "address": "東京都文京区白山(2〜5丁目)",
      • ○: "address": "東京都文京区白山(2〜5丁目)"
      • ×: "address": "東京都文京区音羽",
      • ○: "address": "東京都文京区音羽"
      • ×: "yomi": "チヨダク",
      • ○: "yomi": "チヨダク"
      • ×: "yomi": "チュウオウク",
      • ○: "yomi": "チュウオウク"
      • ×: "yomi": "オガサワラムラ",
      • ○: "yomi": "オガサワラムラ"
  • p.264
    • <input>要素にname属性がない
    • http://twitter.com/iwamot/statuses/13552442097
      • ×: <input id="q" type="text"/>
      • ○: <input id="q" name="q" type="text"/>
      • ×: <input type="radio" name="type" value="json"> JSON,
      • ○: <input type="radio" id="type1" name="type" value="json"/> JSON,
      • ×: <input type="radio" name="type" value="html"> XHTML
      • ○: <input type="radio" id="type2" name="type" value="html"/> XHTML
      • ×: <input type="submit" value="検索"/>
      • ○: <input type="submit" id="submit" name="submit" value="検索"/>
  • p.273
    • 「JSONの配列の最後のカンマは不要(誤りではない)」な件が他にもあった
      • 構文的には間違っていないが、ほかの例はすべて入れていないので統一する
      • ×: "prefecture": "バツバツケン",
      • ○: "prefecture": "バツバツケン"

1刷→2刷の差分(2010/04)

  • p.88
    • TRACEは「プロキシ動作の確認用」ではなく、リクエストの最終(本当の最終ではなく、途中で止まった場合も含め)到達先でのリクエスト受信内容を検査する「ループバック試験用」の命令となります。
      • ×: プロキシ動作の確認
      • ○: 自分宛にリクエストメッセージを返す(ループバック)試験
  • qvalueの説明が間違えている(複数箇所)
    • http://twitter.com/kt001965/status/11839181690
    • http://twitter.com/kt001965/status/11839396105
    • http://twitter.com/kt001965/status/12079988679
    • http://twitter.com/kt001965/status/12080092886
    • http://twitter.com/kt001965/status/12080316493
    • p.132
      • ×: この例の場合、text/html、application/xhtml+xml、application/xmlの3つが0.9という優先度で、それ以外のすべてのメディアタイプ(*/*)が0.8という優先度です。
      • ○: この例の場合、text/html、application/xhtml+xmlがデフォルトの1、application/xmlが0.9、それ以外のすべてのメディアタイプ(*/*)が0.8という優先度です。
    • p.133
      • ×: Accept-Charset: Shift_JIS;utf-8;q=0.7,*;q=0.7
      • ○: Accept-Charset: Shift_JIS,utf-8;q=0.7,*;q=0.7
      • ×: この例ではShift_JISとUTF-8およびそれ以外のすべてのエンコーディング方式が優先度0.7で並んでいますが、Shift_JISとUTF-8のほうがより具体的であるため、こちらの2つを優先します。
      • ○: この例ではShift_JISと、Accept-Charsetヘッダのデフォルト文字エンコーディングISO 8859-1がqvalueのデフォルト値である優先度1になりますが、より具体的なShift_JISを優先します。これらに続いて、UTF-8およびそれ以外のすべてのエンコーディング方式が0.7の優先度となります。
      • ×: この例では日本語(ja)とアメリカ英語(en-us)が優先度0.7で、地域を特に指定しない英語(en)が優先度0.3で続きます。
      • ○: この例では日本語(ja)がデフォルトの1、アメリカ英語(en-us)が0.7、地域を特に指定しない英語(en)が0.3という優先度です。
  • <form>要素のaction属性とtarget属性が間違えている(複数箇所)
    • ついでに、method属性、action属性の順番を統一した(誤りではない)
    • ついでに、method属性の値のメソッド名を大文字に統一した(誤りではない)
    • http://twitter.com/sakuro/statuses/12046716170
    • p.98
      • ×: <form action="GET" target="/list">
      • ○: <form method="GET" action="/list">
      • ×: <form action="POST" target="/list">
      • ○: <form method="POST" action="/list">
    • p.99
      • ×: <form target="/list/item1" action="post">
      • ○: <form method="POST" action="/list/item1">
    • p.169
    • p.170
      • ×: ターゲットURIは<form>要素のtarget属性で指定します。
      • ○: ターゲットURIは<form>要素のaction属性で指定します。
      • ×: そのときに用いるメソッドは<form>要素のaction属性で指定します。
      • ○: そのときに用いるメソッドは<form>要素のmethod属性で指定します。
      • ×: action属性の値がGETの場合、
      • ○: method属性の値がGETの場合、
    • p.171
      • ×: action属性の値がPOSTの例を見てみましょう。
      • ○: method属性の値がPOSTの例を見てみましょう。
      • ×: <form target="http://example.jp/article" action="POST">
      • ○: <form method="POST" action="http://example.jp/article" >
      • ×: action属性がPOSTの場合、
      • ○: method属性がPOSTの場合、
    • p.264(誤りではないが統一のため)
  • p.209表の注
    • first が fist になっている
    • http://twitter.com/kt001965/status/11826540220
      • ×: ※fistとlastは、RFC 5005ではなく、Atomの仕様策定後にIANAに提案されたリンク関係
      • ○: ※firstとlastは、RFC 5005ではなく、Atomの仕様策定後にIANAに提案されたリンク関係

修正しない

※フィードバックをいただいたけど、修正しないと判断した事項です。

改訂時の変更内容(機能追加)

※何年後かの改訂時に検討する事項です。大幅な変更が行えます。なお、改訂が行われるかどうかは未確定です。

  • 402は使っているとこもある旨、捕捉?
  • ふわふわした技術は本書では取り上げなかったの件
    • トークセッションでの発言
      • どのような技術をとりあげ、どのような技術はとりあげないかについて冒頭で明記
  • p.14
    • 「Web以前の分散システムの問題点」は、Sun方面で警句化された下記文書への言及を注釈に入れると、資料価値が上がる他、後年のRPC-over-HTTP批判への流れなども見えやすくなると思います。
    • http://en.wikipedia.org/wiki/Fallacies_of_Distributed_Computing
      • ありがとうございます。改訂時に検討します
  • p.48
    • URIでの日本語の扱いに関連して、策定完了しているIRI(W3C勧告/RFC 3987)へポインタを張っておくと有用かと思います。
      • IRIは入れるかどうか悩んだのですが、普及度合いを見てやめました。改訂時に再検討します
  • p.74
    • 「レスポンスが返るまで待機」についてはHTTP/1.1のHTTP Pipeliningによって改められました(普及途上ですが)。これは後述のリクエストのべき等性を生かした高速化なので、言及価値があるかと思います。
      • 同じくPipeliningも普及度をみてやめました。ただ、注はあった方が良さそうですね。改訂で検討です
  • p.95
    • PUTとPOSTの使い分けについて:PUTは明示的なリソース操作のため(中間ノードがキャッシュしている場合に)キャッシュの更新・破棄が的確にできるというメリットがあります。また、PUTでの上書きは条件リクエストで抑止できるため、事前チェックをする実装は不必要に冗長な処理をしているものです。
      • ありがとうございます。追加の量が多そうなので改訂時に検討します
  • p.140
    • リクエストの度に401応答に必ずなるわけではなく、サーバーは認証通過後の正常応答でAuthentication-Infoヘッダを介して次回用nonceを返すことができます。
      • ありがとうございます。追加の量が多そうなので改訂時に検討します
  • p.147-148
    • ETagについてコラムを立てているので、その中でStrong/Weakについて言及があると、スケーラビリティへの配慮についての理解という意味で言及価値があるかと思いました
      • ありがとうございます。改訂時に検討します
  • p.236
    • relが抜けている
    • トークセッション中に著者が発見
      • と思ったがrelはリンク関係なので単に足すのではおかしい
      • JSONでもrelというプロパティでリンク関係を使いましょうというのを改訂時に入れる
  • AtomPub
    • AtomPubは少なくとも、RESTful API 設計の実例として参考になったよ
    • http://twitter.com/chinmo/status/11818699728
      • AtomPubは失敗だったかの件と含めて、改訂時に入れることを検討します
  • 書き込み可能なWebサービスのトランザクション
    • サンプルを「atomic transaction で解決できる課題を例として使っているという点と、トランザクションと更新クエリのレイヤ分割がされていない」から、「2相コミットもしくは long-running transaction」へ
    • http://developer.cybozu.co.jp/kazuho/2010/04/rest-re-web-a6d.html

各種検索

  • はてなタイアリー
Last modified: 2013-09-24 Attached files total: 0Bytes