HTTP DELETEの実務設計ガイド：仕様理解・冪等性・条件付きリクエストから分散環境・セキュリティ対策まで徹底解説
エバープレイ編集部はじめに — DELETEリクエストとは何か
HTTPのDELETEメソッドは、指定したリソースをサーバー側から削除することを要求するためのHTTPメソッドです。RESTfulなAPI設計においては「削除（Delete）」の操作を表す代表的な手段として広く使われます。しかし、その振る舞いや実装上の注意点、ステータスコードやキャッシュ、並行制御との関係など、単純に「消す」という言葉の裏には多くの設計上・運用上の判断が隠れています。本コラムではDELETEの仕様的意味、実務での扱い方、セキュリティや分散環境での考慮点などを深掘りして解説します。
HTTP仕様上の位置づけ：セマンティクス（意味）
HTTPの最新仕様（RFC9110, HTTP Semantics）では、DELETEは「ターゲットリソースとその機能の関連を取り除くことを要求する」メソッドと定義されています。DELETEは「安全（safe）」なメソッドではなく、サーバーの状態を変更する非安全メソッドです。一方でDELETEは「冪等（idempotent）」であるとみなされます。つまり、同じDELETEリクエストを何度送ってもリソースの最終的な状態が変わらない（削除された状態に収束する）ことが期待されます。
基本的な挙動と代表的なレスポンスコード
- 204 No Content：削除成功で本体を返す必要がない場合に良く使われます。
- 200 OK：削除の結果として説明的なエンティティ（例えば削除したリソースの情報やステータス）を返す場合に使用。
- 202 Accepted：削除処理を非同期で受け付け、即時に完了しない場合。処理の状態を問い合わせるためのLocationヘッダやジョブIDを返すことが多い。
- 404 Not Found：指定したリソースが存在しない場合。ただし、セキュリティや仕様上、存在しなくても204を返す設計もある。
- 410 Gone：リソースが恒久的に削除され、将来的にも復活しないことを明示したい場合に使用。
レスポンスの扱いはAPI設計方針によって異なります。例：冪等性と情報漏洩対策の観点から、存在しないリソースに対するDELETEに204を返して「存在の有無を明示しない」仕様にするケースがあります。
冪等性と副作用の区別
RFC準拠ではDELETEは冪等とされていますが、これはリソースの最終状態に関する話です。ログ記録やメール通知、ランキング更新などの「副作用」は冪等性の外にあり、同一リクエストの再送が副作用を重複して発生させる可能性があります。したがって、実装側では冪等性を保持したい副作用（重複通知を防ぐ等）については別途対策（デデュープID、トランザクション、条件付き処理など）を行うべきです。
リクエストボディの扱い
DELETEリクエストはボディを持つことが技術的に許容される場合がありますが、仕様上「ボディに標準的な意味は定義されていない」ため、多くの実装はボディを無視します。したがって、単一リソースの削除はURLで指定し、ボディに依存するAPI設計（例：DELETEで複雑なフィルタを渡してバルク削除する）は相互運用性の問題を招く可能性があります。バルク削除が必要ならPOST /bulk-deleteや専用のエンドポイント、または明示的に仕様化されたAPIを用いるのが安全です。
条件付きリクエスト（楽観的排他制御）
並行アクセス対策として、DELETEにも条件付きリクエスト（If-Match、If-Unmodified-Sinceなど）が重要です。たとえば、クライアントが取得したリソースのETagを使って「自分の見ているバージョンと一致する場合のみ削除する」ようにすれば、競合で誤って最新データを削除するリスクを低減できます。もし前提条件が満たされない場合は412 Precondition Failedを返します。
キャッシュとDELETE
一般に、状態を変更するメソッド（PUT/POST/DELETEなど）に対するレスポンスは、特段の明示（Cache-ControlやExpiresなど）がない限りキャッシュすべきではありません。またDELETEが行われた場合、サーバーやプロキシのキャッシュされた表現を無効化（staleにする、削除する）する必要があります。正しいキャッシュ制御を設計しておかないと、古い表現がクライアントに返り続けるなどの問題が発生します。
REST設計上の実務的注意点
- エンドポイント設計：一般的にDELETE /resources/{id}のように個別リソースを指すURLで用いる。
- バルク削除：DELETEで複数を一括削除する設計は相互運用上危険。POSTでバルク操作エンドポイントを用意するか、明確な仕様を提供する。
- 非同期処理：削除が重い処理（外部サービス呼び出しや長時間取引）なら202 Acceptedを返し、ジョブの完了状態を問い合わせる仕組みを用意する。
- エラーハンドリング：存在しないリソース、権限不足、前提条件不一致などを適切なHTTPステータスで返す。
フロントエンドとブラウザの制限
HTMLの
