書籍概要

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 解説付き参考文献

サポート

正誤表

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

(2017年1月5日更新)

全刷共通

P.165 表10.4

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

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

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刷以降および最新の電子版では修正済み
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の3つが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

商品一覧