Contents
- 正誤情報の報告方法
- 検討中のフィードバック
- 増刷時の変更内容(バグフィックス)
- 3刷→4刷の変更予定
- 2刷→3刷の差分(2011/01)
- 1刷→2刷の差分(2010/04)
- 修正しない
- 改訂時の変更内容(機能追加)
- 各種検索
Webを支える技術サポートWiki
『Webを支える技術』の正誤情報などをまとめるWikiです。
正誤情報の報告方法
- Twitterでハッシュタグ#webtechbookを付けて発言してください
- @yohei(著者)、@inao(編集者)も付けていただけると確実です
- このWikiに直接書き込んでいただくのでも大丈夫です(仕様により要ログイン)
検討中のフィードバック
※このWikiに直接報告する場合は、ここに書き込んでください。
- ページ
- 報告内容の要約
- 報告URL
- 増刷時の対応方法(誤→正 or 変更しない理由)
- RESTが先か、Webが先か
- RESTが先と誤読される記述がある
- http://togetter.com/li/19994
- 誤読される表現はどこか調査。増刷で対応できるか、改訂規模じゃないと対応できないかを検討。
増刷時の変更内容(バグフィックス)
※増刷時の変更事項です。基本的に、誤字脱字レベルの細部の変更しか行えません。
3刷→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.99
- <input>要素にname属性がない★name属性が必要な理由をお一言お願いします★★/>に変更する場合は、その旨と理由をお願いします★
- http://twitter.com/iwamot/statuses/13552442097
- ×: <input type="hidden" id="_method" value="PUT">
- ○: <input type="hidden" id="_method" name="_method" value="PUT"/>
- 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属性がない★name属性が必要な理由をお一言お願いします★★id属性を追加しているものもありますね。その旨と理由をお願いします★
- 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属性がない★name属性が必要な理由をお一言お願いします★★id属性を追加しているものもありますね。その旨と理由をお願いします★
- 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.211
- .jpであるべきところが.orgになっている
- ×: <link rel="next-archive" href="http://blog.example.org/201009.atom"/>
- ○: <link rel="next-archive" href="http://blog.example.jp/201009.atom"/>
- ×: <link rel="prev-archive" href="http://blog.example.org/201007.atom"/>
- ○: <link rel="prev-archive" href="http://blog.example.jp/201007.atom"/>
- ×: <link href="http://example.org/201008/32"/>
- ○: <link href="http://example.jp/201008/32"/>
- 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.260
- 検索結果リソースのXHTML表現(「112」の検索結果)の「&」がエスケープされていない( 下から3行目)。ここはXHTMLの属性の値なので、URIの「&」は「&」と記述するのが正しい
- ×: <p><a href="http://zip.ricollab.jp/search?q=112&page=2"
- ○: <p><a href="http://zip.ricollab.jp/search?q=112&page=2"
- p.264
- <input>要素にname属性がない★name属性が必要な理由をお一言お願いします★★id属性を追加しているものもありますね。その旨と理由をお願いします★★閉じタグにスラッシュを付けた旨とその理由をお願いします★
- 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は「プロキシ動作の確認用」ではなく、リクエストの最終(本当の最終ではなく、途中で止まった場合も含め)到達先でのリクエスト受信内容を検査する「ループバック試験用」の命令となります。
- ×: プロキシ動作の確認
- ○: 自分宛にリクエストメッセージを返す(ループバック)試験
- p.90
- JSONの配列の最後のカンマは不要(誤りではない)
- http://twitter.com/kawanet/status/11819804919
- 構文的には間違っていないが、ほかの例はすべて入れていないので統一する
- ×: {"uri": "http://example.jp/list/item4"},
- ○: {"uri": "http://example.jp/list/item4"}
- 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
- ×: <form target="http://example.jp/search" action="GET">
- ○: <form method="GET" action="http://example.jp/search">
- 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(誤りではないが統一のため)
- ×: <form action="http://zip.ricollab.jp/search" method="get">
- ○: <form method="GET" action="http://zip.ricollab.jp/search">
- p.209表の注
- first が fist になっている
- http://twitter.com/kt001965/status/11826540220
- ×: ※fistとlastは、RFC 5005ではなく、Atomの仕様策定後にIANAに提案されたリンク関係
- ○: ※firstとlastは、RFC 5005ではなく、Atomの仕様策定後にIANAに提案されたリンク関係
- p.324
- 98頁の「OPTIONS自体はAllowヘッダには含めません」は自明だからってことなのかな。324頁では含めてるので気になった
- http://twitter.com/iwamot/status/11947570366
- http://twitter.com/iwamot/status/11947868120
- 仕様的には間違っていないのですが、紛らわしいのでp.324のOPTIONSは削除します
- ×: Allow: GET, POST, HEAD, OPTIONS
- ○: Allow: GET, POST, HEAD
修正しない
※フィードバックをいただいたけど、修正しないと判断した事項です。
改訂時の変更内容(機能追加)
※何年後かの改訂時に検討する事項です。大幅な変更が行えます。なお、改訂が行われるかどうかは未確定です。
- URIのモダンな設計作法について追加?
- http://d.hatena.ne.jp/kazuhooku/20101012/1286901973
- "TwitterやFacebookのURLには、なぜ#!が含まれるのか"
- http://d.hatena.ne.jp/karasuyamatengu/20110210/1297363019
- それに対するTim Brayの批判
- http://d.hatena.ne.jp/karasuyamatengu/20110212/1297465199
- 批判2
- URI→URLに?
- http://d.hatena.ne.jp/hatenatech/20100806/1281088801
- "URL ⊃ URI (HTML5)"
- 402は使っているとこもある旨、捕捉?
- http://d.hatena.ne.jp/mala/20100707/1278514965
- もし過剰なアクセスにより金銭的な負担が発生しているのであれば402 payment requiredを返すのも良いでしょう。youtubeが使っています。
- よくJavaScriptなリンクを見るけど、それってREST的にどうなのか?
- 以下を読んでいてふと気になりました。
- インピーダンスミスマッチ
- http://togetter.com/li/14062
- Vol.42の鼎談、紙面で、REST-OO-RDB間それぞれのインピーダンスミスマッチが話題になっていた(http://gihyo.jp/dev/serial/01/rest)
- 後述しているCRUDの重力とも絡む
- ふわふわした技術は本書では取り上げなかったの件
- トークセッションでの発言
- どのような技術をとりあげ、どのような技術はとりあげないかについて冒頭で明記
- Cookie
- http://www.machu.jp/diary/20100416.html#p01
- Vol.58のessaさんインタビュー etc
- RestfulなCookieの取り扱い方
- 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.142
- OpenID の辺り。2.0 仕様書だと、Identity Provider (IdP) は OpenID Provider (OP)、Service Provide (SP) は Relying Party (RP) かしらん。
- http://twitter.com/nsiena/status/11956058875
- http://twitter.com/nsiena/status/11956062320
- http://twitter.com/nsiena/status/11956064163
- 改訂時の状況をみて判断したいと思います
- p.142
- OAuth の辺り。いずれ、Service Provider は Server、Consumer は Client に。コミュニティ仕様書では前者、策定中の草案だと後者。
- http://twitter.com/nsiena/status/11956093192
- http://twitter.com/nsiena/status/11956095093
- http://twitter.com/nsiena/status/11956097007
- 改訂時の状況をみて判断したいと思います
- p.236
- relが抜けている
- トークセッション中に著者が発見
- と思ったがrelはリンク関係なので単に足すのではおかしい
- JSONでもrelというプロパティでリンク関係を使いましょうというのを改訂時に入れる
- URI
- URIリファクタリングのノウハウとか欲しい
- http://twitter.com/lchin/status/11817560423
- HTTP
- CRUDの重力
- http://twitter.com/chinmo/status/11817684799
- http://twitter.com/yojik_/status/11817891876
- 入れるなら第5部かまだ見ぬ第6部ですね。一度RESTにはまったあとに反省する章になりそうです
- HTML
- HTML5のフォーム
- http://twitter.com/lchin/status/11817885099
- http://twitter.com/lchin/status/11818002918
- http://twitter.com/lchin/status/11818640992
- HTML5については改訂時の状況を見て判断したいと思います
- HTML
- HTML5のmicrodata
- http://twitter.com/nsiena/status/11829256692
- http://twitter.com/jacotan/status/11818664180
- HTML5については改訂時の状況を見て判断したいと思います
- AtomPub
- AtomPubは少なくとも、RESTful API 設計の実例として参考になったよ
- http://twitter.com/chinmo/status/11818699728
- AtomPubは失敗だったかの件と含めて、改訂時に入れることを検討します
- 第5部
- 楽々ERDレッスン化
- http://twitter.com/jacotan/status/11818941946
- 改訂で対応でるかどうか…
- 書き込み可能なWebサービスのトランザクション
- サンプルを「atomic transaction で解決できる課題を例として使っているという点と、トランザクションと更新クエリのレイヤ分割がされていない」から、「2相コミットもしくは long-running transaction」へ
- http://developer.cybozu.co.jp/kazuho/2010/04/rest-re-web-a6d.html
- p.297のER図の正規化が甘い
- http://wp.serpere.info/archives/1214
- 楽々ERDレッスン化と合わせて対応したい…
- その他
- ハッシュタグを紙面で告知してほしい
- http://twitter.com/pyonchang/status/11987260328
- http://twitter.com/nsiena/status/11998284744
- 要検討ですね
各種検索
- ハッシュタグ(#webtechbook)
- 書名(Webを支える技術)
- はてなブックマーク
- タグ(webtechbook)
- この商品を含む新着ブックマーク(ASIN4774142042)
- 書名(Webを支える技術)
- はてなタイアリー
- この商品を含むはてなダイアリー(ASIN4774142042)
Last modified: 2011-02-13
Attached files total: 0Bytes