よくある捉え方
CRUD に合わせて以下のように考えがち。
- Create → POST
- Read → GET
- Update → PUT
- Delete → DELETE
しかーし！ ここで多くの人が詰まる。この４つで足りない処理は？ と。
実際にシステムを作ってみればわかるが、この４つでは足らないのが普通なのだ。
しかし、HTTP メソッドを創作するわけにはいかない。何かが間違っているのだ。
メソッド本来の意味
POST はポスティングのポストである。つまり、投函のイメージ。やった回数分だけ反映される。
GET は取得。何度取得しても、取得したことによって変化を生じさせない。
PUT は置くこと。日本語で言ってしまえば 登録。何度やっても１度やるのと変わらない。
DELETE は削除。何度やってもよい。成功すりゃ消えとるしね。
まとめると……
ここで注目したいのが、POST と PUT との違い。POST は呼ばれるたびに作用する。PUT は何度やっても同じデータを登録するだけ。つまり、データベースで ID（主キー）を持つようなデータの登録は、PUT なのだ。いくらそれが初登録で、SQL で言えば INSERT 文であろうと、それは PUT の仕事なのだ。つまり、「日本語で言ってしまえば 登録」と書いたが、UPSERT とか MERGE と言われる処理全般において、それは PUT の仕事なのだ。ただし、ID（主キー）が自動生成で、呼ばれるたびに増えていくものであれば、ID を示しているわけではなく、新しいものを生成し追加してちょ！ という意味なので、それは PUT ではなく、POST ということになる。つまり、こういうことだ。
| HTTP メソッド | DB 操作 | CRUD | 説明 |
|---|---|---|---|
| PUT | INSERT, UPDATE | C, U | 登録 |
| GET | SELECT | R | 取得 |
| DELETE | DELETE | D | 削除 |
| POST | 単純ではないヤツ | どれでも | 指示、命令、要求など |
POST だけ仲間はずれ。そう、POST は汎用的に使えるメソッドなのだ。つまり、指示書を投函（POST）するイメージ。他の３つは、リソースに対して登録・取得・削除するということ。だから、POST を使用するときは指示の内容は Body に JSON などで書くべき。URL は、その指示書を投函する窓口を指すものであるのが望ましい。