郵便局の「窓口」と「ポスト」の違い：HTTPのPOSTメソッドが「非冪等」である理由
皆さん、こんにちは。ネットワークの深淵を覗き込み、パケットの鼓動を愛してやまないインフラアーキテクトです。
Web APIの開発において、避けては通れないのが「REST APIの設計」ですよね。特に「メソッド」の使い分けは、APIの美しさを決める重要なポイントです。その中でも、新人エンジニアが最初に躓きやすいのが、POSTメソッドの持つ「非冪等（ひべきとう）性」という概念です。
今回は、この少し難しそうな言葉を、私たちの身近にある「郵便」の仕組みに例えて紐解いていきましょう。
—
そもそも「冪等（べきとう）」って何？
数学用語のような響きですが、ITの世界では「何度同じ操作をしても、結果が同じになること」を指します。
例えば、テレビのリモコンで「電源ボタン」を押す操作を考えてみてください。
一度押せば電源が入り、もう一度押せば切れる……これは「冪等ではない」操作です。でも、「音量を上げるボタン」はどうでしょう？ 10回押せば、音量は10段階上がりますよね。
APIの世界でも、この「何度やっても同じ結果になるか？」という性質が、エラー処理や再試行（リトライ）を設計する上で非常に重要になってくるのです。
—
POSTは「郵便局の窓口」、GETは「私書箱の確認」
POSTメソッドは、リソース（データ）を「新規作成」する時に使います。これを郵便に例えると、「窓口で書留を出す」行為に近いです。
あなたが郵便局の窓口へ行き、「この手紙を速達で送ってください！」と頼むとします。
もし、窓口の人が通信トラブルで「すみません、もう一度お願いします」と言ったとき、あなたは同じ手紙をもう一度差し出しますよね。するとどうなるか？ 相手には「同じ内容の手紙が2通」届いてしまいます。
これが POST の「非冪等性」です。
「同じ操作を繰り返すと、新しいデータがその分だけ増えてしまう」という特性を持っているんですね。
一方で、GET（データの取得）は、自分の私書箱を確認するようなものです。1回覗いても100回覗いても、中身が変わらない限り、郵便物は増えませんよね。これが「冪等」な操作です。
—
なぜ「非冪等」だと困ることがあるの？
ネットワークの世界は、実はとても不安定です。パケットが途中で迷子になったり、サーバーからの応答がタイムアウトしたりすることは日常茶飯事です。
もし、あなたが「注文ボタン」を押したときに、サーバーからの「受付完了！」という返事を受け取れなかったらどうしますか？ 不安になって「もう一度ボタンを押す」はずです。
もしこれが POST の設計を無視して、「何度押しても1つの注文しか入らないように」工夫していなかったら、「同じ商品を2つ注文してしまった！」という悲劇が起こります。
—
実務での対策：重複を防ぐには？
「じゃあ、POSTは危なくて使えないの？」というと、そんなことはありません。現場では「冪等キー（Idempotency Key）」という仕組みを使って、この問題を解決するのが一般的です。
例えば、クライアント側で「このリクエストは一意ですよ」という番号をヘッダーに含めて送る方法です。
# Pythonでのリクエスト送信イメージ
import requests
# クライアント側で生成した一意なID（UUIDなど）
# これをヘッダーに含めることで、サーバー側で重複を検知します
headers = {
"Idempotency-Key": "550e8400-e29b-41d4-a716-446655440000",
"Content-Type": "application/json"
}
data = {
"item_id": 123,
"quantity": 1
}
# POSTメソッドで注文を送信
# サーバー側では、このキーが既に処理済みかを確認します
response = requests.post("https://api.example.com/orders", json=data, headers=headers)サーバー側では、この Idempotency-Key をデータベースに記録しておき、「同じキーが来たら、2回目は新規作成せず、前回の結果を返す」という処理を実装します。これが、プロの現場で行われている「安全な設計」です。
—
まとめ：一歩ずつ理解していきましょう！
POSTメソッドが「非冪等である」ということは、「新しいものを作る力がある分、扱いには注意が必要」というサインだと覚えておいてください。
1. POSTは新規作成！（毎回新しいリソースができる）
2. ネットワークは失敗するもの！（リトライが起きても大丈夫な設計を）
3. 冪等キーで安全を守る！（識別子を使って重複を制御する）
これらを意識するだけで、あなたの作るAPIは、まるで熟練の職人が書いたような、堅牢で美しいものに変わります。
最初は難しく感じるかもしれませんが、まずは「この操作を2回繰り返したら、データはどうなるかな？」と想像する癖をつけてみてください。その視点こそが、優秀なインフラ・バックエンドエンジニアへの第一歩です。
それでは、また次回の深淵でお会いしましょう！
コメント