DELETEメソッドの「冪等性」とステータスコード：現場で迷わないためのAPI設計指針
ネットワークエンジニアの端くれとして、これまで数多のトラフィックと格闘してきましたが、意外と「仕様の曖昧さ」でトラブルを招きやすいのがHTTPメソッドの挙動です。
特に`DELETE`メソッド。ただリソースを消すだけ――そう思っていませんか？
しかし、インフラからアプリケーションまでを俯瞰する立場から言わせれば、ここには「冪等性（Idempotency）」という、分散システムの根幹に関わる重要な設計思想が隠れています。今日は、RFC 7231/9110の仕様をベースに、実務で迷わないための「正しいDELETEの作法」を紐解いていきましょう。
—
1. DELETEにおける「冪等性」の正体
まず、言葉の定義を整理しましょう。冪等性とは、「同じ操作を何度繰り返しても、結果（リソースの状態）が同じであること」を指します。
`DELETE`メソッドは、「リソースを消去する」という目的において、冪等であると定義されています。
- 1回目: リソースを削除し、サーバーは成功を返す。
- 2回目以降: すでに削除済みなので、リソースは存在しない。結果として「存在しない」状態は初回と変わらないため、冪等とみなされる。
ここで重要なのは、「2回目のレスポンスが、1回目と同じである必要はない」という点です。ここを勘違いして、「2回目も必ず200 OKを返すべきだ」と設計すると、キャッシュ戦略や監視ロジックで足元をすくわれます。
—
2. 現場で選ぶべき「ステータスコード」の最適解
リソースの削除処理において、エンジニアが最も頭を悩ませるのがステータスコードの選択です。RFCの仕様に基づき、以下の3パターンを使い分けるのがプロの流儀です。
成功時の選択肢
1. `200 OK`: 削除成功。レスポンスボディに詳細な削除結果や、現在のリソース状態を含める場合に適しています。
2. `202 Accepted`: 非同期処理。バックエンドでバッチ処理が走る場合など、「受理はしたが完了は保証しない」ときに使います。
3. `204 No Content`: 個人的には最も推奨します。 削除が完了し、返すコンテンツが何もない（ヘッダーのみ）場合に最適です。フロントエンドのFetch APIでも扱いやすく、パケットサイズも最小限で済みます。
存在しないリソースへのDELETE
- `404 Not Found`: 削除しようとしたリソースがそもそも存在しない場合。
- `410 Gone`: そのリソースがかつて存在したが、明示的に削除され、今後もアクセスされるべきではないことが分かっている場合。SEOやプロキシのキャッシュ制御で非常に有効です。
—
3. 実践：DELETEリクエストを投げるコード例
現場でデバッグやAPIの動作確認を行う際、よく使われる手法をいくつか紹介します。
curlで疎通確認を行う（デバッグの基本）
まずはブラウザを閉じて、CLIで直接確認しましょう。`-v`オプションは必須です。
204 No Content が返ってくることを期待する例
curl -X DELETE -v https://api.example.com/v1/items/12345 \
-H “Authorization: Bearer
Fetch API（JavaScript）での実装
フロントエンドで実装する場合、`204`を適切にハンドリングすることが重要です。
async function deleteItem(id) {
const response = await fetch(`/api/items/${id}`, {
method: ‘DELETE’,
headers: { ‘Content-Type’: ‘application/json’ }
});
// 204 No Contentの場合は、レスポンスボディをパースしようとしないこと！
// ここでエラーを吐くエンジニアが非常に多いです。
if (response.status === 204) {
console.log(‘削除完了’);
return;
}
if (response.ok) {
return await response.json();
} else {
throw new Error(‘削除失敗’);
}
}
—
4. インフラ屋からのTips：注意すべき落とし穴
最後に、ネットワークアーキテクトとしての警告を一つ。
「冪等だからといって、DELETEにリクエストボディを含めてはいけない」
RFCではDELETEメソッドでのリクエストボディの送信を明確に禁止していませんが、多くのゲートウェイ、ロードバランサー（L7）、キャッシュサーバーは、DELETEリクエストのボディを無視したり、最悪の場合パケットをドロップしたりします。
もし「削除対象の条件」を複雑に送りたい場合は、それは`DELETE`ではなく、`POST`で専用のエンドポイントを叩くか、クエリパラメータで指定するのがWebの作法です。
最後に
DELETEは単なる「削除」ではなく、リソースの状態を「不在」へ遷移させるプロトコルアクションです。この仕組みを正しく理解し、204と404を適切に使い分けるだけで、APIの堅牢性は劇的に向上します。
「動けばいい」というコードから、「仕様を理解した、メンテナンス性の高いコード」へ。皆さんのAPI設計がより洗練されたものになることを願っています。何か疑問があれば、またいつでも聞いてください。
コメント