【入門編】HTTP/1.1におけるDELETEメソッドの冪等性とステータスコード – HTTPプロトコル・通信規格実践ガイド

こんにちは！ネットワークの世界へようこそ。
Webブラウザで何かを表示する時、裏側では「HTTP」というプロトコル（通信のお約束）が猛スピードで走り回っています。今日はその中でも、ちょっと扱いが繊細な「DELETEメソッド」について、一緒に紐解いていきましょう。

「データを消す」という行為、現実世界ならゴミ箱に捨てるだけですが、ネットワークの世界ではもう少しだけお行儀の良いルールがあるんです。

—

HTTPメソッドを語る上で避けて通れないのが「冪等性（Idempotency）」という言葉。漢字ばかりで難しく見えますよね。でも、考え方はとてもシンプルです。

「何回同じ操作をしても、結果が（副作用的に）同じであること」

これを指します。例えば：

では、今回の主役DELETEはどうでしょうか？

—

結論から言うと、DELETEは「冪等」です。

郵便配達に例えてみましょう。
あなたは「私の住所のポストの中身を空にしてください」という手紙を出しました。配達員は中身を捨てて、ポストを空にします。
では、次に同じ手紙を出したらどうなるでしょう？
配達員はポストを見ますが、既に空なので「あ、もう空だ」と確認して帰るだけですよね。

「消しに行く」という操作を何回繰り返しても、「そのリソースが存在しない状態」という結果に落ち着く。 だから、DELETEは冪等なんです。

—

さて、ここからがエンジニアの腕の見せ所です。
「データを消せ！」と命令した時、サーバーはどんな顔で返事をすべきでしょうか？ HTTP/1.1の仕様では、主に以下のコードが使われます。

200 OK: 「消したよ！これが消したデータの詳細だよ」と、削除後のメッセージを返したい時に使います。
204 No Content: 「消したよ！もう中身は何もないから、返事も特になし！」というスッキリした返答です。REST APIの現場ではこちらが好まれることが多いですね。

ここが議論の分かれ道です。「既に消えているもの」をDELETEしようとした時、エラー（404）を返すのが一般的です。

「えっ？冪等なら、何度叩いても成功（200）でいいんじゃないの？」と思うかもしれません。しかし、多くのシステムでは「消そうとしたターゲットが見当たらない」という事実は、クライアントに「指定したパスが間違っているかもよ？」と教えてあげる親切心から、404を返す設計が推奨されています。

—

実際に、Webサーバー側でDELETEを受け取った時の動きを擬似コードで見てみましょう。

// DELETEリクエストが来た時のサーバーの心構え
app.delete(‘/items/:id’, (req, res) => {
const item = database.find(req.params.id);

// 1. もしデータが見つからなかったら
if (!item) {
// 「そもそも対象が存在しません」と伝える（404）
return res.status(404).send(‘対象が見当たりません’);
}

// 2. データがあれば削除を実行
database.remove(req.params.id);

// 3. 削除成功！「もう何もないよ」と伝える（204）
return res.status(204).send();
});

—

DELETEメソッドにおける「冪等性」は、単なるプログラミングの理屈ではありません。
「何度リクエストを送っても、システムの最終状態が壊れない」という安心感を担保するためのものなのです。

これらを守るだけで、あなたの書くAPIはグッと信頼性が高まり、他のエンジニアからも「おっ、わかってるね！」と言われるはずです。

ネットワークの通信は、まるで手紙のやり取りです。相手にどう伝われば一番気持ちいいか。そんな視点を持つと、プロトコルの学習もぐっと楽しくなりますよ。また次回お会いしましょう！