Java | Web 基礎・HTTP・REST：HTTP 基礎 － DELETE の役割

DELETE を一言でいうと

DELETE は
「この URL が指しているものを“消して”」とサーバーに頼むためのメソッド
です。

ユーザー削除
商品削除
お気に入り解除
など、「そのリソース自体をなくす・無効にする」操作を表現するときに使います。

DELETE の基本イメージ

URL で「何を消すか」を指定する

DELETE は、URL で「どれを消すか」をはっきり指定します。

例えば、ID=1 のユーザーを削除したいときのリクエストはこうなります。

DELETE /api/users/1 HTTP/1.1
Host: example.com

DELETE /api/users/1 HTTP/1.1
Host: example.com

意味はそのまま
「/api/users/1 というユーザーを削除して」
です。

サーバー側は、
その ID のユーザーが存在するかを確認し、
存在すれば削除し、
適切なステータスコードを返します。

Java（Spring）での DELETE の書き方

@DeleteMapping を使う

Spring では、DELETE は @DeleteMapping で表現します。

@DeleteMapping("/api/users/{id}")
public void delete(@PathVariable Long id) {
    userService.delete(id);
}

@DeleteMapping("/api/users/{id}")
public void delete(@PathVariable Long id) {
    userService.delete(id);
}

ここでやっていることはシンプルで、

URL の {id} から削除対象の ID を受け取り
サービス層に「この ID を削除して」と依頼する

だけです。

レスポンスとしては、
ボディなしで 204 No Content を返すことが多いです。

@DeleteMapping("/api/users/{id}")
public ResponseEntity<Void> delete(@PathVariable Long id) {
    userService.delete(id);
    return ResponseEntity.noContent().build(); // 204
}

@DeleteMapping("/api/users/{id}")
public ResponseEntity<Void> delete(@PathVariable Long id) {
    userService.delete(id);
    return ResponseEntity.noContent().build(); // 204
}

「削除が成功したけど、返す中身は特にないよ」という意味になります。

DELETE の性質：冪等（べきとう）である

同じ DELETE を何回送っても最終状態は同じ

DELETE は、本来 冪等（べきとう） なメソッドとされています。

冪等とは、
「同じリクエストを何回送っても、最終的な状態が変わらない」
という性質です。

例えば、

1 回目の DELETE /api/users/1 → ユーザー ID=1 を削除
2 回目の DELETE /api/users/1 → すでにいないので何も起きない

どちらにせよ、
「最終的にユーザー ID=1 は存在しない」という状態は同じです。

実装としては、
2 回目以降は 404 Not Found を返すか、
204 No Content を返すか、
などの選択肢がありますが、
「状態としては変わらない」というのがポイントです。

DELETE と GET / POST との違い

GET との違い：状態を変えるかどうか

GET は「読むだけ」で、サーバーの状態を変えません。
DELETE は「消す」ので、サーバーの状態を変えます。

だから、
「削除なのに GET /deleteUser?id=1」
のような設計は絶対に避けるべきです。

検索エンジンやブラウザの事前読み込みが GET を勝手に叩いたら、
意図せずデータが消える、という事故につながります。

POST との違い：何を表現しているか

POST は「新しく作る」「何か処理を実行する」など、
「増やす・起こす」方向の操作が多いです。

DELETE は「なくす」方向の操作です。

URL の意味も違います。

POST /api/users
→ users という集合に新しい user を追加

DELETE /api/users/1
→ users の中の 1 番を削除

この「集合に追加する POST」と「個体を消す DELETE」の対比を意識すると、
REST の設計がかなりスッキリ見えてきます。

実務での DELETE のよくあるパターン

物理削除と論理削除

現場では、「削除」といっても 2 種類あります。

物理削除：
DB からレコード自体を消す。
本当にいなくなる。

論理削除：
deleted フラグや deleted_at カラムを立てて、
「削除された扱い」にするだけ。
データ自体は残る。

DELETE メソッドは、
HTTP 的には「そのリソースを削除する」という意味ですが、
実際に DB で物理削除するか、論理削除にするかは、
ビジネス要件次第です。

Java のサービス層では、

public void delete(Long id) {
    var user = userRepository.findById(id)
            .orElseThrow(...);
    user.markDeleted(); // 論理削除
}

public void delete(Long id) {
    var user = userRepository.findById(id)
            .orElseThrow(...);
    user.markDeleted(); // 論理削除
}

のように、
「HTTP 的には DELETE、実装としては論理削除」
ということもよくあります。

「本当に消していいの？」の確認はフロント側で

DELETE は破壊的な操作なので、
UI では「本当に削除しますか？」の確認ダイアログを出すのが普通です。

ただし、
その確認はあくまでフロントエンドの責務です。

バックエンド（Java）は、
「DELETE が来たら、適切な権限チェックと削除処理を行う」
ことに集中します。

初心者向けまとめ：DELETE を自分の言葉で説明するなら

あなたの言葉で整理すると、こうなります。

DELETE は、
「この URL が指しているリソースを削除して」とサーバーに頼むメソッド。

DELETE /api/users/1 のように、
URL で「どれを消すか」を指定し、
Java（Spring）では @DeleteMapping で実装する。

同じ DELETE を何度送っても、
最終的に「そのリソースが存在しない」という状態は変わらない、
という意味で冪等なメソッド。

実装としては、
物理削除にするか論理削除にするかはビジネス次第だが、
HTTP 的には「そのリソースはもう利用できない」という意味を表す。

もしよければ、
「ユーザー削除」「コメント削除」「お気に入り解除」など、
あなたがイメージしやすい機能を一つ選んで、
URL・メソッド・レスポンスを一緒に設計してみよう。
そこを自分で言語化できるようになると、DELETE の使いどころが一気にクリアになるから。