POST を一言でいうと
POST は
「サーバーにデータを送りつけて、“何かしらの処理をしてもらう”ためのメソッド」
です。
特に重要なのは、
新しいデータ（リソース）を作成する
サーバー側の状態を変える
という「書き込み系の役割」を持っていることです。
GET が「読むだけ」なら、POST は「書き込む・登録する・実行してもらう」側だと思ってください。
POST の一番典型的な役割：新規作成（Create）
ユーザー登録を例にする
いちばんイメージしやすいのは「ユーザー登録」です。
ユーザーが画面のフォームに
名前
メールアドレス
パスワード
などを入力して「登録」ボタンを押す。
このときブラウザは、サーバーに対して POST リクエストを送ります。
POST /api/users HTTP/1.1
Content-Type: application/json
{"name":"Alice","email":"alice@example.com","password":"secret"}
意味は「この JSON の内容で、新しいユーザーを作ってください」です。
サーバー側（Java）は、これを受け取って DB に保存し、
作成されたユーザー情報をレスポンスとして返します。
Java（Spring）でのコード例
@PostMapping("/api/users")
public UserResponse create(@RequestBody UserRequest request) {
var user = userService.register(request);
return UserResponse.from(user);
}
ここでやっていることは、
リクエストボディ（JSON）を UserRequest として受け取り
ビジネスロジック（userService.register）でユーザーを作成し
作成結果を UserResponse として返す
という「新規作成」の流れです。
「新しく何かを作る」は、まず POST を疑う、という感覚を持っておくとよいです。
POST のもう一つの顔：「処理の実行」を頼む
「作成」だけでなく「何かして」が含まれる
POST は「新規作成」が代表例ですが、
「サーバー側で何か処理をしてほしい」というときにも使われます。
例えば、
レポート生成
バッチ処理のトリガー
メール送信リクエスト
など、「何かアクションを起こしてほしい」ときです。
POST /api/reports/monthly HTTP/1.1
Content-Type: application/json
{"year":2025,"month":4}
意味は「2025 年 4 月の月次レポートを作ってください」です。
サーバーはこのリクエストを受けて、
レポートを生成し、
結果の URL やステータスを返す、
といったことができます。
GET との違いを意識する
同じ「レポートを見る」でも、
すでに作成済みのレポートを取得する → GET
まだ存在しないレポートを新たに作らせる → POST
というように、
「サーバー側の状態が変わるかどうか」でメソッドを分けます。
POST とボディ（リクエスト本体）
データは URL ではなくボディに載せる
GET はクエリパラメータで条件を渡すことが多いですが、
POST は「ボディ」にデータを載せるのが基本です。
JSON
フォームデータ
ファイル（バイナリ）
など、さまざまな形式のデータをボディに詰めて送れます。
Java（Spring）では、@RequestBody で JSON を受け取り、MultipartFile などでファイルを受け取ります。
@PostMapping("/api/upload")
public void upload(@RequestParam("file") MultipartFile file) {
fileService.store(file);
}
URL に載せるには大きすぎるデータや、
機密性の高いデータ（パスワードなど）は、
基本的に POST のボディで送る、と覚えておくと安全です。
POST の性質：「安全ではない」「冪等ではない」
安全ではない（サーバーの状態を変える）
HTTP の世界では、
GET のように「読むだけで状態を変えない」メソッドを「安全（safe）」と呼びます。
POST は、
新規作成や処理実行によってサーバーの状態を変えるので、
安全ではありません。
だからこそ、
認証・認可（誰が実行してよいか）
入力チェック
CSRF 対策
などが特に重要になります。
冪等ではない（同じリクエストを何度も送ると結果が増えることがある）
冪等（べきとう）とは、
「同じリクエストを何度送っても結果が変わらない性質」のことです。
PUT や DELETE は、
同じリクエストを何度送っても最終状態は同じ、という意味で冪等です。
一方 POST は、
同じリクエストを 2 回送ると、
ユーザーが 2 人作られる
注文が 2 件発行される
といったことが起き得ます。
つまり、
POST は「冪等ではない」のが普通です。
だから、
ボタン連打
ネットワークのリトライ
ブラウザの再送信確認
などに気をつける必要があります。
実務では、
サーバー側で重複チェックをしたり、
クライアント側で二重送信を防いだりして、
POST の「増えやすさ」をコントロールします。
Java 開発者視点での「POST をいつ使うか」
まずは「新規作成は POST」と体に染み込ませる
ユーザー登録
商品登録
コメント投稿
注文作成
こういった「まだ存在しないものを作る」処理は、
まず POST を選ぶのが自然です。
Spring では、
@PostMapping("/api/xxx")
と見たら、
「ああ、これは何かを作るか、何か処理を起こすエンドポイントなんだな」
と直感できるようになっていきます。
「状態を変えるが、URL で対象を特定しない」ものも POST
PUT や DELETE は、
URL で「どのリソースか」を特定してから操作します。
PUT /api/users/1DELETE /api/users/1
一方、POST は、
「親リソースの下に新しいものを追加する」
「何か処理を起こす」
といった用途で、URL が「集合」や「アクション」を表すことが多いです。
POST /api/users（集合 users に新しい user を追加）POST /api/reports/monthly（月次レポート生成というアクション）
この違いを意識できると、
REST API の URL 設計もだんだん気持ちよくなってきます。
初心者向けまとめ：POST を自分の言葉で説明するなら
あなたの言葉で整理すると、こうなります。
POST は、
サーバーにデータを送りつけて、
「新しいリソースを作ってほしい」
「何か処理を実行してほしい」
と頼むためのメソッド。
サーバー側の状態を変えるメソッドで、
安全ではなく、冪等でもない。
だから、同じ POST を何度も送ると、
同じものが何個も作られることがある。
Java（Spring）では、@PostMapping で表現し、@RequestBody や @RequestParam でボディやパラメータを受け取り、
新規作成や処理実行のロジックを Service に書いていく。
もしよければ、
「ユーザー登録」「コメント投稿」「注文作成」あたりを題材にして、
URL・メソッド・リクエストボディ・レスポンスを一緒に設計してみよう。
そこを自分で設計できるようになると、POST が一気に“使える武器”になるから。