概要

HTTP・URI・RESTの設計思想を原理から理解してWebサービス設計に活かす

想定読者

Web APIやサービスを設計・実装する機会のある初〜中級エンジニア。「なんとなくGETとPOSTを使い分けている」段階を脱し、HTTPとRESTの意味論を根拠ある判断軸として身につけたい人

こんな人には向いていない

• RESTful API設計を実務で数年こなし、OpenAPI仕様策定や設計レビューを日常的に行っている上級者には体系の再確認以上の発見は少ない
• GraphQL・gRPC・WebSocketなど2010年以降に台頭したプロトコルの実装知識を求める読者には対応していない（本書の対象範囲外）
• コードサンプル中心に手を動かしながら学びたい読者には向かない。本書は設計思想・仕様の解説が主体でコードはほぼ出てこない

この本で身につくこと

• HTTPメソッド（GET/POST/PUT/DELETE/PATCH）の意味と使い分け根拠を仕様レベルで説明できる
• リソース指向でURIを設計し、変更に強い命名・構造を判断できる
• RESTの6制約（ステートレス・統一インターフェース等）とその設計上の意味を理解できる
• クライアント・サーバの役割分担をHTTPの仕様から逆算して決定できる
• コンテントネゴシエーションやHTTPヘッダを意識したAPIレスポンス設計ができる

ハイライト(外部からの言及)

ＨＴＴＰやＵＲＩ、ＨＴＭＬなどの仕様を歴史や設計思想を織り交ぜて解説。そしてＷｅｂサービスにおける設計課題、たとえば望ましいＵＲＩ、ＨＴＴＰメソッドの使い分け、クライアントとサーバの役割分担、設計プロセスなどについて、現時点でのベストプラクティスを紹介 — 出典

「仕様の歴史・設計思想」と「現場のベストプラクティス」を橋渡しする本書の立ち位置を端的に示している。実装ガイドでなく原理の書であることが読み取れる

1度読んだだけで理解できなくても、Webサービスの設計や実装を経験してから再度読み直すとWebの仕組みがスッと頭に入ってきて理解が進む。 — 出典

実務経験を積んだ後に再読すると理解が深まるという体験談。「最初は半分も掴めなくていい」という読み方の指針を示しており、書籍の内容範囲を説明する既存ハイライトとは学習軌跡の角度で補完する

読んでて楽しい本ではなかったけど、これを読んでいたおかげで転職したあとも比較的スムースに会話についていくことができたので読んでおいてよかった本です。 — 出典

「楽しさ」より「職業的な実用性」という率直な評価。読了後に現場での語彙・文脈の共有が可能になるという実務インパクトを正直に示しており、購入判断を後押しする独立した角度として機能する

読了後にできること

Before(読む前): HTTPメソッドの選択やURIの命名をなんとなく決めており、「なぜGETでなくPOSTか」を設計レビューで問われると根拠を言語化できなかった

After(読み終えた後): RESTの制約とHTTPの仕様を出発点に、URIとメソッドの選択を設計根拠とともに説明・レビューできる

章立て

第1章 Webとは何か

第1部 Web概論。本書全体の問題意識を設定する起点

第2章 Webの歴史

HypertextからWorld Wide Webへの系譜を辿る章。「なぜRESTがこの設計になったか」を理解するための歴史的背景として第3章のREST論に接続する。初読時は流し読みで問題ない。

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

Fielding の REST を「アーキテクチャスタイル」として整理する核心章。以降の章はすべてここから派生する

第4章 URIの仕様

第2部 URI

第5章 URIの設計

「Cool URIs don't change」の原則を実装に落とす章。API レビューで頻繁に参照される

第6章 HTTPの基本

第3部 HTTP

第7章 HTTPメソッド

GET/POST/PUT/DELETE のべき等性・安全性を仕様レベルで判別する章。実務直結度が最も高い

第8章 ステータスコード

現場でよく使う 200/201/204/301/303/304/4xx/5xx を根拠を持って選び分けるための章

第9章 HTTPヘッダ

Authorization・Cache-Control・Content-Typeなど業務頻出ヘッダの意味と使い分けを整理する。第7章(メソッド)・第8章(ステータスコード)と組み合わせて読むとHTTP全体像が繋がる。

第10章 HTML

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

第11章 microformats

HTMLにセマンティクスを付与する仕様群。現在はschema.org/JSON-LDが主流でmicroformats直接利用は少ないが、「HTMLにデータの意味を埋め込む」設計思想の理解に使う。参考程度に読む位置づけ。

第12章 Atom

RSSの後継XMLシンジケーションフォーマット。現代APIではJSONが主流でAtomの直接利用は限定的だが、リンク関係とフィード構造を通じてHATEOAS設計思想を学ぶケーススタディとして価値がある。

第13章 Atom Publishing Protocol

HATEOAS の具体例として読むケーススタディ。現代では JSON / Hypermedia API に置き換えて読む

第14章 JSON

REST APIのデータ交換フォーマットとして最も普及するJSONの仕様を解説する章。第16章の書き込みAPI設計演習の前提として押さえておくと設計判断の根拠が明確になる。

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

第5部 Webサービスの設計

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

POST・PUT・DELETEによるリソース更新のパターンを具体的に解説する章。第15章(読み取り専用)と対になる構成で、本書の中で最も実務のAPI設計に近い例が登場する。設計レビュー前の再読価値が高い。

第17章 リソースの設計

本書の総合演習にあたる設計演習章。これまでの章の知識を統合して使う

関連記事 / 参考情報

• 【Webエンジニアど素人から３年生ぐらいになるまでに読むと良い本】を段階的にまとめた — 入門〜中級ロードマップの中で本書をWeb技術基礎の必読書として段階的に位置づけている
• Webエンジニア1年目の自分に捧げたい本・記事を超まとめ — 1年目エンジニアが読んでおくべき技術書として本書を推薦している
• API設計まとめ — REST API設計の参考書として本書を参照。HTTPメソッドとリソース設計の根拠書として位置づけている
• 図解！ネットワークの7層を実務に当てはめてみた — ネットワーク階層とHTTPの実務対応を解説する文脈で本書を関連推薦している
• 「HTTPとは何か？」を完全に理解する〜分かったフリの脱却〜 — HTTPの仕組みを「なんとなく」から原理へ理解し直す文脈で本書を参照している
• 「Webを支える技術」の内容のまとめ — 本書のREST・URI設計・HTTPメソッド各章を読者が自ら体系的にまとめた記事

学習のヒント

• REST原則とHTTPメソッドの章は、URI設計やAPI設計の判断が迫られる場面の前に読み返す価値が高い。通読後も「設計レビューで根拠を問われた時の参照先」として手元に置く使い方が有効
• チームメンバーへのWeb基礎説明資料を作る際の下書きとして活用しやすい。概念の要約が簡潔で引用しやすい構成になっている
• 2010年刊行のため、OAuth 2.0・OpenAPI・JSON:API など2015年以降の周辺仕様は本書でカバーできない。読了後はRFC文書やWeb API: The Good Partsをセットで参照してギャップを埋めることを推奨

前提知識

• ブラウザとサーバの間でリクエスト/レスポンスが行き来するという程度の概念的理解
• 実際にWebアプリケーションかAPIをひとつ動かした経験（言語・フレームワーク不問）

次に読む本

Web API: The Good Parts

「Webを支える技術」がHTTPとRESTの原理・設計思想を扱うのに対し、本書はエンドポイント命名・バージョニング・エラーレスポンス設計など現代的なAPI実装パターンを網羅する。原理の次に実装指針を身につける順序として、REST概念を掴んだ直後に読むと効果的。

RESTful Webサービス

Roy Fielding のREST論文に近い視点でRESTシステム設計を詳解する原典寄りの書籍。「Webを支える技術」がRESTの概要と実用例を示すのに対し、本書はリソースモデリングの判断軸や設計手順をより深く扱う。REST設計を業務で主導する立場になる前に読むと理解が体系化される。

HTTPの教科書

「Webを支える技術」がHTTPをREST設計の文脈で紹介するのに対し、本書はリクエスト/レスポンスの構造・キャッシュ制御・Keep-Alive・TLS連携など通信プロトコルとしての挙動を専門的に解説する。HTTPヘッダの仕様詳細やトラブルシューティングが必要な場面で参照する位置づけ。