Web技術（HTTP・URI・REST）

Webを支える中心の技術は3つです。URIはリソース（情報やモノ）に世界中で一意な名前をつけ、HTTPはそのリソースを取得・操作するための決まった手順を定め、HTMLなどのハイパーメディアはリソース同士をリンクで結びます。どのサーバーもどのクライアントも同じ約束事に従うので、間にプロキシやCDNを挟んだり、サーバーを増やしたりしても全体が動き続けます。

山本陽平『Webを支える技術』は、この3つとRESTを、仕様と設計の両面から解説した定番の本です。おおまかな構成と、SREとして特に押さえたい点を対応させると次のとおりです。

本が書かれた後に広く使われるようになったもの（HTTP/2・HTTP/3、OAuth 2.0とOpenID Connect、JWT、GraphQLとgRPC、WebSocket、CORS、セキュリティヘッダなど）も、SREの実務では欠かせないので、この章で合わせて扱います。

RESTは、HTTPの仕様策定に関わったRoy Fieldingが博士論文で示したアーキテクチャスタイル（設計の型）です。中心にあるのはリソースという考え方で、「ユーザー42」「今日の天気」のような、名前をつけて指し示す価値のある情報をすべてリソースとみなし、URIで名前をつけます。クライアントがやりとりするのはリソースそのものではなく、その時点の状態をJSONやHTMLで表した表現です。

RESTは複数の制約の組み合わせです。中でもSREにとって重要なのはステートレスとキャッシュです。ステートレスとは、サーバーがクライアントの状態（何ページ目を見ているかなど）を覚えず、リクエストに必要な情報を毎回すべて含めることです。どのサーバーでも同じように処理できるので、ロードバランサの後ろに台数を増やすだけでスケールできます。その代わり、毎回送る情報が増える、という欠点があります。

実務の「REST API」の多くはレベル2です。SREの観点では、レベル2まで守られていると、ステータスコードで監視でき、GETはキャッシュやリトライが安全にでき、LBやWAFがメソッドを見て制御できる、という恩恵があります。

セッションをサーバーのメモリに持つと、ステートレスが崩れてスケールしにくくなる。

URI（Uniform Resource Identifier）は、リソースを一意に識別する名前です。よく聞くURLは、URIのうち「どこにあるか（場所）」を表すもので、Webで使うURIはほぼURLと考えて差し支えありません。部品は、スキーム（https）、ホスト（api.example.com）、ポート、パス（/v1/users/42）、クエリ（?fields=name）、フラグメント（#top）です。フラグメントはブラウザの中だけで使われ、サーバーには送られません。URIに使えない文字（日本語、空白、一部の記号）はパーセントエンコード（例：空白は%20）して送ります。

「クールなURIは変わらない」という有名な言葉のとおり、URIは外部からリンクされ、ブックマークされ、検索エンジンに登録されるので、一度公開したら変えないのが原則です。どうしても変えるなら、古いURIから新しいURIへ301（恒久的な移動）でリダイレクトします。APIのバージョンをURIに入れる（/v1/）か、ヘッダーで指定するかは流派がありますが、URIに入れる方式はルーティングやログの集計がしやすく、運用面で扱いやすいです。

SREとしての注意点：クエリ文字列にトークンや個人情報を入れると、アクセスログ、CDNのログ、ブラウザの履歴、Refererヘッダーに残ります。秘密の値はヘッダーか本文で送ります。また、クエリ文字列の順番や不要なパラメータがCDNのキャッシュキーに入ると、ヒット率が下がります。

スキーム・ホスト・ポートまでがオリジン。CORSやCookieの範囲を考えるときの基本単位。

HTTPのメッセージは、1行目（リクエストならメソッド・パス・バージョン、レスポンスならステータス）、ヘッダー、空行、本文（ボディ）でできています。HTTPはTCP（HTTP/3ではQUIC）の上で動き、HTTPSはその間にTLSを挟んだものです。curl -v を使うと、実際に送られたリクエストとレスポンスのヘッダーを見られるので、障害調査の基本ツールになります。

$ curl -v https://api.example.com/v1/users/42
> GET /v1/users/42 HTTP/2
> Host: api.example.com
> User-Agent: curl/8.5.0
> Accept: */*
>
< HTTP/2 200
< content-type: application/json
< cache-control: private, max-age=0
< x-request-id: 9f1c...
<
{"id":42,"name":"..."}

HTTPはステートレスです。サーバーは前のリクエストを覚えておらず、ログイン状態などはCookieやトークンで毎回送ります。これによりどのサーバーでも処理でき、障害時に別のサーバーへ振り替えやすくなります。

ヘッダーを見れば、キャッシュの扱い、認証の有無、どのプロキシを通ったかが分かる。

HTTP/2以降は接続の本数が減るので、LBの接続数の見え方も変わる。

安全（safe）とは、呼んでもリソースの状態を変えないことです。冪等（idempotent）とは、1回呼んでも何回呼んでも、結果として同じ状態になることです。SREにとってこの性質が重要なのは、ネットワークの瞬断やタイムアウトで「成功したか分からない」ときに、冪等なメソッドなら安心してリトライできるからです。LBやプロキシ、クライアントライブラリの中には、冪等なメソッドだけを自動でリトライするものもあります。

POSTは冪等ではないので、タイムアウト後にリトライすると二重注文や二重決済になります。決済や注文のAPIでは、クライアントが一意なIdempotency-Keyヘッダーを付け、サーバーは同じキーの2回目以降に最初の結果を返すようにします。また、GETで状態を変える作り（GET /delete?id=1 など）は、クローラーやプリフェッチ、キャッシュによって意図せず実行されるので避けます。

冪等かどうかで、リトライしてよいかが決まる。

エラーの本文は、形式をそろえると調査と監視が楽になります。標準としてRFC 9457（Problem Details）があり、type、title、status、detailなどの項目を持つJSONで返します。どのコードを返すかに加えて、「誰が返したか」（アプリか、LBか、CDNか、WAFか）をログで区別できるようにしておくと、障害の切り分けが速くなります。

SLOでは5xxを失敗として数えるのが基本。4xxは利用者の誤りなので通常は除くが、急増には注意。

502 の定番原因として、ALB のアイドルタイムアウトよりバックエンドの Keep-Alive タイムアウトが短いと、ALB が閉じられた接続を使って 502 になる、というものがある。

コードを見れば、どこを調べに行くべきかが分かる。

CORSに関係するヘッダーはCORSの解説、キャッシュの詳しい使い方はHTTPキャッシュの解説で解説しています。独自ヘッダーに「X-」を付ける慣習は、標準化の際に名前を変えにくくなるため、新しく作るものには推奨されていません。

curl -v やブラウザの開発者ツールでヘッダーを読む習慣をつけると、調査が速くなる。

If-Matchを使うと、DBの楽観ロックと同じことをHTTPのレベルで実現できます。GETで受け取ったETagをPUTやPATCHのときにIf-Matchで送り、サーバーは今のETagと違えば412を返します。複数の人が同じ文書や設定を編集する画面で、気づかないうちに他人の変更を上書きする事故を防げます。

コンテンツネゴシエーションは、同じURIのリソースを、クライアントの希望（Accept、Accept-Language、Accept-Encoding）に応じて別の表現で返す仕組みです。たとえば圧縮（gzip、br）や言語の切り替えです。このときレスポンスにVaryヘッダー（例：Vary: Accept-Encoding）を付けないと、CDNが別の表現を取り違えてキャッシュし、文字化けや別言語のページが表示される事故になります。

412を受け取ったクライアントは、最新を取り直して利用者に確認させる。

Webのリクエストは、ブラウザ、CDN、リバースプロキシ、アプリのキャッシュ（Redisなど）、DBのバッファプールと、何層ものキャッシュを通ります。手前で返せるほど速く、奥の負荷が減ります。HTTPのキャッシュは、主にレスポンスのCache-Controlヘッダーで制御します。

期限が切れたら、ETag（内容の識別子）やLast-Modifiedを使って「前回から変わったか」だけを確認します（If-None-Match）。変わっていなければ304 Not Modifiedが本文なしで返り、転送量を節約できます。

CDNは、URLなどから作るキャッシュキーで「同じリクエストか」を判断します。キャッシュキーに含めない要素（Cookie、Authorizationヘッダー、言語など）でレスポンスが変わるページをキャッシュすると、他人のページが表示される重大事故になります。ログイン後のページや個人情報を含むAPIは、no-storeやprivateにするか、CDNでキャッシュしない設定にします。

どの層でキャッシュしているかを把握していないと、「どこで古いデータが返っているか」を追えない。

max-ageの間はオリジンに届かず、期限切れ後は304で本文を省略できる。

オリジンは「スキーム＋ホスト＋ポート」の組み合わせです。ブラウザには同一オリジンポリシーがあり、あるオリジンのページのJavaScriptが、別のオリジンに送ったリクエストのレスポンスを読むことを禁止しています。これがないと、悪意のあるサイトが、あなたのログイン中のCookieを使って銀行のAPIを呼び、その結果を盗めてしまうからです。

しかし画面（app.example.com）とAPI（api.example.com）を分けるのは普通の構成です。そこでCORS（Cross-Origin Resource Sharing）を使い、APIサーバーがレスポンスヘッダーで「app.example.com からなら読んでよい」と宣言します。ブラウザはそのヘッダーを確認して、許可されていればJavaScriptにレスポンスを渡します。

大事なポイントは、CORSはブラウザが守るルールだということです。curlやサーバー同士の通信には関係ありません。だから「curlでは成功するのにブラウザだけでエラーになる」が典型的な症状です。また、単純なリクエストの場合、サーバーは処理を実行してレスポンスも返していて、ブラウザがJavaScriptに渡さないだけ、ということもあります。CORSはサーバーを守る仕組みではないので、CSRF対策などは別に必要です。

PUTやDELETE、JSONの送信、独自ヘッダーの付与など「単純でない」リクエストの前には、ブラウザが自動でOPTIONSメソッドのプリフライトを送り、許可を確認します。単純なリクエストは、GET・HEAD・POSTで、ヘッダーとContent-Typeが限られたもの（フォーム送信やtext/plain）だけです。

httpとhttps、サブドメイン違い、ポート違いはすべて別オリジン。

ブラウザの開発者ツールのネットワークタブで、OPTIONSとレスポンスヘッダーを見ると原因が分かる。

OAuth 2.0は「認可」（何をしてよいか）の仕組みで、アプリに利用者のパスワードを渡さずに、許可した範囲のトークンだけを渡します。ブラウザやスマホのアプリでは、認可コードフローとPKCEを使うのが現在の推奨です。ログイン（認証）にはOAuth 2.0の上に作られたOpenID Connectを使います。

すぐ無効化したいならセッション、スケールのしやすさならトークン。組み合わせることも多い。

アプリが受け取るのはパスワードではなく、範囲と期限の決まったトークン。

第11章「セキュリティ」：認証の種類と強化（MFA・SSO・パスキー）

設計の手順は、『Webを支える技術』で紹介されている流れが参考になります。提供するデータを洗い出し、URIで指せるリソースに分け、名前（URI）をつけ、表現の形を決め、リンクで結び、典型的な使われ方とエラーを検討します。

『Webを支える技術』の第4部では、HTML、microformats、Atom、JSONといったハイパーメディアのフォーマットが紹介されています。今日のAPIはほとんどがJSONですが、「レスポンスに関連リソースや次のページへのリンクを含める」という考え方は、カーソル方式のページングなどに生きています。

最後の「エラーを検討する」を飛ばすと、障害時に原因の分からないAPIになる。

フロントエンドの置き方は、画面の作り方で決まります。ReactやVueで作ったSPAのように、ビルドするとHTMLとJSのファイルになるなら、S3に置いてCloudFrontで配信するのが基本です。サーバーを持たないので、スケールや障害の心配がほとんどありません。SEOのために最初からHTMLを返したい、利用者ごとに画面を作りたい、という場合はNext.jsなどのSSR（サーバーサイドレンダリング）が必要で、ECS・Lambda・専用のホスティングサービスで動かします。

構成のポイントは、画面とAPIを同じドメインの下に置いて、CloudFrontでパスごとに振り分けることです（/ はS3、/api/* はALB）。オリジンが同じになるのでCORSの設定が不要になり、Cookieの扱いも単純になります。S3は公開せず、OAC（Origin Access Control）でCloudFrontからだけ読めるようにします。デプロイでは、ファイル名にハッシュを入れたJSや画像は長くキャッシュし、index.htmlは短くするか毎回確認させます。

同じドメインでパスを分けると、CORS・Cookie・証明書の管理がまとめて楽になる。

ReactやVueのアプリは、数百〜数千のファイルとnpmのライブラリでできています。そのまま配ると読み込みが遅いので、バンドラー（Vite、webpack、esbuild、Rollup、Turbopackなど）がビルド時にまとめます。主な処理は、ファイルを少数にまとめるバンドル、空白や長い名前を削って小さくするminify、使われていないコードを捨てるtree shaking、画面ごとに必要になってから読むコード分割（遅延読み込み）です。

出力は大きく2種類です。名前が毎回同じindex.html（入口）と、中身のハッシュが名前に入ったJS・CSS・画像（assets/index.3f9a1c.js など）です。中身が変われば名前も変わるので、ハッシュつきのファイルは1年などの長いキャッシュにしても、新しい版と混ざりません。逆に、index.htmlを長くキャッシュすると、利用者はいつまでも古い版を読み続けます。

index.htmlは短く、ハッシュつきファイルは長く。これを逆にすると事故になる。

フロントエンドのデプロイは、中身（assets）を先に、入口（index.html）を最後に差し替えるのが原則です。逆の順番だと、新しいindex.htmlが、まだアップロードされていないJSを読みに行って画面が壊れます。また、デプロイ前にページを開いたままの利用者は、画面遷移のタイミングで古いJSの分割ファイルを取りに来るので、古いassetsはすぐに消さず、数世代残してから後で掃除します。

ビルドはCIで1回だけ行い、同じ成果物をステージングから本番へそのまま昇格させます。APIのURLなど環境ごとの値をビルド時に埋め込むと環境ごとに作り直すことになるので、実行時にconfig.jsonなどから読む形にしておくと安全です。切り戻しは、前の版のindex.htmlに戻すだけで済むようにしておきます。

index.htmlを最後に差し替え、古いassetsは残す。この2つでほとんどの事故は防げる。

サーバー側のメトリクスは正常なので、RUMやエラー監視がないと気づけない。

常時接続の方式は、LBのタイムアウトとデプロイ時の再接続を必ず設計に含める。

MCPは、Anthropicが2024年に公開したオープンな仕様で、Claudeなどを使うAIアプリ（ホスト）が、社内のAPIやデータベース、SaaSなどにつながるための共通の差し込み口です。ホストの中のMCPクライアントが、各MCPサーバーとJSON-RPCでやりとりします。サーバーは、AIが呼び出せるツール（操作）、読み取れるリソース（データ）、定型のプロンプトを提供します。

MCPサーバーの後ろにある社内システムの権限が、そのままAIの権限になる。