What is the difference between GET, POST, PUT, PATCH and DELETE?
Quick Answer
GET reads a resource (safe, idempotent, cacheable). POST creates a resource or triggers processing (not idempotent). PUT replaces a resource entirely at a known URL (idempotent). PATCH applies a partial update (not necessarily idempotent). DELETE removes a resource (idempotent).
GET reads and never changes anything — it's safe and idempotent and can be cached. POST creates a resource or kicks off some processing, and it's not idempotent, so calling it twice can create two records. PUT replaces a resource completely at a URL the client already knows, and it is idempotent — same call twice, same result. PATCH is a partial update, just the fields that changed. DELETE removes the resource and is idempotent — deleting something that's already gone is still a success. The reason safe and idempotent matter is retries: a client can safely retry a PUT or DELETE that timed out, but retrying a POST needs an idempotency key or you double up.
| Verb | Purpose | Safe | Idempotent | Typical success code |
|---|---|---|---|---|
| GET | Retrieve | Yes | Yes | 200 |
| POST | Create / process | No | No | 201 (+ Location) or 200/202 |
| PUT | Create or fully replace at a specific URL | No | Yes | 200 / 204 |
| PATCH | Partial update | No | Not required | 200 / 204 |
| DELETE | Remove | No | Yes | 204 (or 200) |
- Safe = no server state change (GET). Idempotent = making the same call twice has the same effect as once.
- PUT vs POST for create —
PUT /customers/42when the client chooses the id;POST /customerswhen the server assigns it. - PUT vs PATCH — PUT sends the whole resource; PATCH sends only the changes (JSON Merge Patch or JSON Patch).
- Idempotency matters for retries — a client can safely retry a failed PUT/DELETE, but retrying a POST may double-create (use an idempotency key).