PUT vs PATCH vs POST
Updated 2026-11-13 · 3 min read
Compare HTTP method intent, idempotency and update payloads, with practical checks for API testers. Includes a comparison table, concrete examples and an interview answer.
The difference in one table
| Aspect | PUT | PATCH | POST |
|---|---|---|---|
| Intent | Create or replace target resource state | Apply a set of changes to a resource | Process submitted content using target-specific semantics |
| Typical example | Replace a saved address at a known URI | Change one address field | Submit an order to a collection |
| Payload meaning | Desired replacement representation | Changes described by the patch media type | Defined by the endpoint contract |
| Idempotent by definition? | Yes | No; a particular patch can be idempotent | No; a particular API can provide duplicate protection |
| Testing focus | Replacement and repeated-request effect | Patch rules, atomicity and concurrency | Processing outcome and retry behaviour |
Examples
These are hypothetical API designs, not ShopLite endpoints.
PUT: replace the editable representation of a saved address at a client-known URI. Test what happens to omitted fields according to the contract; do not silently assume they remain unchanged.
PATCH: change the address label without replacing the rest. A patch that assigns a fixed label can be idempotent; a patch that appends an entry might not be. Test the supported patch document format and ensure a failed patch does not leave a partially applied change.
POST: submit an order. If a response is lost, a retry must follow the API's documented duplicate-protection mechanism. Do not assume the server safely deduplicates merely because the payload is identical.
How to answer in an interview
PUT requests creation or replacement of the target resource state, PATCH describes changes, and POST asks the target to process the submitted content. PUT is idempotent by HTTP semantics; PATCH and POST do not have that general guarantee. For address changes, I verify replacement versus partial-update rules and read the media-type contract. For order creation, I explicitly test documented retry and duplicate-protection behaviour.
Common confusion
POST is not limited to creation, and PUT is not limited to updates. Idempotency describes the intended effect of repeated identical requests, not identical status codes or response bodies. A PUT may create a resource on one call and replace it on another.
Likely follow-up: How do you avoid overwriting another user’s edit? Test the API’s documented conditional-update mechanism, such as an ETag precondition; do not assume a partial update solves concurrency.
Quick answers
Is PATCH always JSON?
No. Its media type defines the patch document. A JSON-looking body alone does not tell you whether it is JSON Patch, Merge Patch or a custom format.
Can POST be retried safely?
Only with evidence from the operation contract or another reliable way to know whether it was applied. A method name alone does not provide duplicate protection.
Sources
Want a project you can show in interviews?
The portfolio project kit walks you through testing a deliberately buggy app with Selenium or Playwright and API tests, then explaining it. The app itself is free.