要約

  • RFC 9110ではmethod tokenが要求セマンティクスの主な情報源であり、クライアントの目的と成功時の期待を示す。一方、各対象リソースが実装・許可を個別に決める。
  • Safeはクライアントが要求した意味を限定するが、全副作用を消さない。Idempotentは反復時の意図された効果を限定するが、応答、ログ、外部結果の同一性を保証しない。
  • 機微な操作には、メソッド、対象、認証主体、認可、前提条件、最初の試行が適用済みかという不確実性、アプリケーション上の冪等性、再試行者、応答、最終状態、外部効果を結合した記録が必要である。

PUTという語が見えれば、何が起きるか分かったように感じる。だが、分かるのはクライアントがどの種類の結果を求めたかである。サーバーがその語を知っているか、対象が受け付けるか、この主体に権限があるか、想定した版がまだ現行か、処理が完了したかは別々の問いだ。

この分離は煩雑さではない。接続が切れ、応答だけが失われたとき、どの問いの証拠が欠けているかを判断するための構造である。

共通語彙が伝えるのは要求の目的

RFC 9110は、メソッドが要求の目的と、クライアントが成功と考える結果を示すと定義する。GETは現在の表現を求める。PUTは選んだ対象に表現された状態を作成または置換する。DELETEは対象URIと現在の機能との対応を外すよう求めるのであり、保存された全データの物理消去までは約束しない。

標準メソッドが異なるリソースでも同じ意味を保つから、汎用部品はアプリケーション固有の知識なしに限定的な判断ができる。キャッシュは取得と変更を区別し、クローラーは安全な方法を扱い、クライアントは通信障害後の反復可能性を考えられる。

ただし、各リソースは実装と許可を自ら決める。未認識または未実装なら501、認識・実装済みでも対象が対応しないなら405が適切である。405のAllowは対象が現在対応するメソッドを示し、その集合は変わり得る。

Allowは権限表ではない。リソースがPUTを扱えることと、匿名利用者がPUTできることは異なる。認証は主体を確かめ、認可は主体・操作・対象に方針を適用し、メソッド対応は処理能力を示す。三つの判断を同じ欄に入れてはいけない。

Heng LuのMinimum Initial Specificationの観点では、共通層は相互運用に必要な意味だけを厳密に共有する。その先の事業ルールは、実際にリソースを動かす参加者に残る。IANAの登録簿は語彙を整えるが、全リソースの許可を決めない。

Safeは無害という称号ではない

Safeなメソッドは、定義された意味が本質的に読み取りであり、クライアントがオリジンサーバーの状態変更を求めていないことを表す。RFC 9110は、アクセスログの追記や広告アカウントへの課金など、実装上の副作用が残り得ると明記する。重要なのは、それをクライアントが要求しておらず、追加行動の責任を負わせられないことだ。

リンク検査、検索インデックス、プリフェッチが機能するのは、この責任分界があるからである。page?do=deleteをGETしただけで削除する設計は、危険な意図をクエリに隠したリソース側の欠陥だ。自動処理がURIをたどった結果を利用者の削除意思と扱ってはならない。

監査では、要求された状態変化と、サーバーが付加した効果を分ける。ログ、課金、クォータ消費、追跡、外部通知は後者に属する。Safeは認可済みという意味でもない。機密情報のGETは読み取りでも、権限がなければ拒否される。

Idempotentは一枚の複製を作る性質ではない

同一要求を複数回適用したとき、意図されたサーバー効果が一回と同じなら冪等である。RFC 9110ではPUT、DELETE、安全なメソッドが該当する。各試行を別々に記録し、複数の改訂履歴を残し、違う応答を返すことは妨げられない。

最初のDELETEが成功し、次のDELETEが「すでにない」と返しても、目標状態は同じである。PUTも同じ状態に収束しながら、日付やvalidatorが変わることがある。

アプリケーションが公開された意味を破る場合もある。置換のはずのPUTが残高を加算すれば、反復は結果を増やす。DELETEのたびに外部決済や通知を新規送信すれば、ローカル状態が収束しても外部効果は増殖する。

したがって、プロトコル上の性質に加えて、operation key、commit状態、下流ごとの重複排除、補償手段が必要になる。メソッドの冪等性は分散トランザクションではない。

再試行は「最初に何が起きたか分からない」を扱う

応答を読む前に接続が切れると、要求が届かなかったのか、処理後に応答だけ失われたのか分からない。冪等な要求を繰り返せる理由は、最初が成功していても同じ意図された効果に収束するはずだからだ。

RFC 9110は無制限の自動再試行を認めない。非冪等メソッドは、そのリソースで実際に冪等だと分かるか、最初の要求が適用されなかったと検出できる場合を除き、自動で繰り返すべきではない。プロキシは非冪等要求を自動再試行してはならず、失敗した自動再試行をさらに自動反復すべきでもない。

判断材料は、切断点、対象、内容、前提条件、アプリケーションのキー、照会可能な処理状態、回数とbackoffである。安定した業務キーを持つPOSTは回復可能なことがある。外部効果を重複排除できないPUTは危険になり得る。

Running-Code Primacyが求めるのは、登録された形容詞ではなく、運用者が検証できる収束、照会、境界である。

If-Matchは版を守り、人物を証明しない

If-Matchは、対象のETagがクライアントの知る値と一致する場合だけ変更を適用させる。条件が偽なら通常412を返し、古いコピーで他者の変更を上書きすることを防ぐ。

ETagを知っていても書込み権限は得られない。権限があっても古いETagは新しくならない。認可は「この主体が行えるか」、前提条件は「想定した状態がまだ存在するか」を答える。拒否理由も別々に保存すべきだ。

応答喪失後には、現在の状態から最初の変更済みと判断できる場合がある。しかし、似た変更を複数主体が非協調で行う資源では誤認が起きる。回復可能性はメソッド名だけでなくリソースモデルに依存する。

QUERYは私的な知識を共通の意味に変える

2026年6月のRFC 10008はJulian Reschke、James Snell、Mike Bishopによるもので、Fieldingの著作ではない。QUERYはPOSTのように内容を運びながら、安全で冪等な照会であることを表す。IANA登録簿でもSafe、Idempotentがともにyesとなった。

複雑な照会をURIに入れると長さやログ露出の問題があるため、読み取りにPOSTを使う実装は多い。だが汎用部品には、そのPOSTが状態を変えず反復可能だと見えない。QUERYはこの意図を公開しつつ、内容の意味と実装判断を対象リソースに残す。

登録は配備ではない。ゲートウェイが転送しない、サーバーが501を返す、対象が405を返す、主体が認可されない可能性は残る。登録簿はアクセス制御表ではなく、採用者が共有できる語彙の台帳である。

Fieldingの署名は貢献を追跡可能にする

2026年8月31日に確認したIETF Datatrackerは、Roy T. FieldingをAdobeのSenior Principal Scientist、The Apache Software Foundation共同創設者、RESTアーキテクチャスタイルの著者、HTTP・URI・URI Templates標準の貢献者と記す。18件のRFCとHTTP Directorateのレビュアー役も掲載する。UC Irvineは学位とWeb、REST、Apacheへの貢献を記録している。

博士論文で統一インターフェースは、可視性、再利用、拡張性、独立進化を高める一方、アプリケーション専用の効率を一部失う制約として説明される。HTTPメソッドはその取引をよく示す。共通の意図は見えるが、保存、認可、実行の内部は資源側に残る。

RFC 9110の編集者はFielding、Mark Nottingham、Julian Reschkeの3人である。HTTPは集合的で継続的な仕事だ。RFC 10008は記載された著者に帰属する。Fieldingはプロトコルの所有者でも、全実装の決定者でもない。

動詞の後ろに操作記録を置く

方法と対象URI、origin、認証主体、credential scope、リソースの対応判断、認可方針と版、ETag、内容hash、意図された効果を記録する。障害時には、最後に確認した送信点、最初の適用可能性、operation key、再試行者、理由、回数、backoffを加える。最後に応答、読み直した状態、下流効果、補償、不可逆部分を保存する。

この連結により、短いtokenは適切な役割に戻る。メソッドは何を求めたかを示す。リソースは理解可能性を、認可は主体の権利を、前提条件は状態の現行性を、再試行証拠は反復の妥当性を、最終観測は実際の結果を示す。

メソッドは意図を名づける。許可を与えるものではない。

出典