GET vs POST vs PUT vs PATCH vs DELETE (2026): HTTP Methods Compared

GET vs POST vs PUT vs PATCH vs DELETE

The five main HTTP methods map to CRUD: GET reads, POST creates, PUT replaces, PATCH partially updates and DELETE removes. The two comparisons interviewers ask most:

• PUT vs PATCH — PUT sends the whole resource and replaces it; PATCH sends only the changes.
• POST vs PUT — POST creates a new resource each time (not idempotent); PUT sets a resource at a known URL to a given state (idempotent).

For request/response examples of every method, see HTTP Methods & Status Codes.

Comparison at a Glance

Safe = doesn't change server state. Idempotent = sending the same request once or many times leaves the server in the same state.

PUT vs PATCH ⭐

Start with this user:

{ "id": 101, "name": "Asha", "email": "asha@example.com", "phone": "9876543210", "city": "Pune" }

PATCH — send only what changes

PATCH /users/101
{ "email": "asha.k@example.com" }

→ { "id": 101, "name": "Asha", "email": "asha.k@example.com", "phone": "9876543210", "city": "Pune" }

Only the email changed; everything else stayed.

PUT — send the whole resource

PUT /users/101
{ "name": "Asha", "email": "asha.k@example.com" }

→ { "id": 101, "name": "Asha", "email": "asha.k@example.com", "phone": null, "city": null }

PUT means "make the resource look exactly like this". Because phone and city were left out, a strictly RESTful API clears them (some APIs instead reject the request with 400 for missing fields). This is the most common PUT bug in real systems — and the reason clients use PATCH for single-field changes.

Why PATCH isn't guaranteed to be idempotent

PATCH { "email": "x@y.com" } gives the same result every time — idempotent. But a PATCH that says "add 1 to loginCount" or "append this item to the list" changes the result every time it's sent. The method allows both, so the HTTP spec doesn't promise idempotency for PATCH.

Two PATCH formats you may meet

• JSON Merge Patch (application/merge-patch+json) — send a partial object, as above; null means "remove this field".
• JSON Patch (application/json-patch+json) — send a list of operations: [{ "op": "replace", "path": "/email", "value": "x@y.com" }].

Most APIs just accept a partial JSON object with Content-Type: application/json — check the API documentation.

POST vs PUT

• POST /users — "create a new user; you choose the ID". Sending it twice creates two users.
• PUT /users/101 — "user 101 should look like this". Sending it twice leaves one user 101 in the same state. Some APIs let PUT create the resource if it doesn't exist (201), when the client knows the ID.

GET and DELETE in One Line Each

• GET only reads. It must never create or change data — browsers, caches and crawlers may repeat GET requests freely. A GET that modifies data is a design defect worth reporting.
• DELETE removes a resource. It's idempotent: after the first call the resource is gone, and repeat calls leave it gone (they may return 404, but the state is the same).

How to Test Each Method

Testing PATCH and PUT idempotency in REST Assured

// PATCH changes only the email
given().contentType(ContentType.JSON).body(Map.of("email", "asha.k@example.com"))
.when().patch("/users/101")
.then().statusCode(anyOf(is(200), is(204)));

given().when().get("/users/101").then()
    .body("email", equalTo("asha.k@example.com"))
    .body("phone", equalTo("9876543210"))          // untouched
    .body("city", equalTo("Pune"));                 // untouched

// PUT twice → same final state
Map<String, Object> full = Map.of("name", "Asha", "email", "asha.k@example.com",
                                  "phone", "9876543210", "city", "Pune");
for (int i = 0; i < 2; i++) {
    given().contentType(ContentType.JSON).body(full).when().put("/users/101")
           .then().statusCode(anyOf(is(200), is(204)));
}
given().when().get("/users/101").then().body("city", equalTo("Pune"));

Design full positive and negative sets for each method in the API Testing Scenario Lab.

The Interview Answer

"PUT replaces the whole resource, so the client sends every field and anything missing may be cleared; PATCH sends only the fields to change and leaves the rest untouched. PUT is idempotent; PATCH isn't guaranteed to be, because a patch can be something like 'increment a counter'. When I test PATCH, I always GET the resource afterwards to prove the other fields didn't change, and for PUT I check how missing fields are handled and that repeating the request gives the same result."

From Real Projects

I've worked with APIs at the level this page covers: CRUD operations, HTTP methods, JSON and XML formats, and extracting and validating values with JSON path. A good habit from that work: test the full create–read–update–delete cycle for a resource and check each response in detail. Testsigma supports web, mobile and API test automation, so understanding APIs was part of understanding the product I was testing. PUT replaces the whole resource and PATCH changes part of it — check both behaviors in your tests. Further reading: Practice REST Assured HTTP methods & Request Data Exercises.

📚 Official documentation: MDN: HTTP

Frequently Asked Questions

What is the difference between PUT and PATCH?

PUT replaces the entire resource with the one sent; PATCH applies partial changes and leaves other fields untouched.

Which HTTP methods are idempotent?

GET, HEAD, OPTIONS, PUT and DELETE. POST isn't; PATCH isn't guaranteed to be.

What status codes do PUT and PATCH return?

200 with the updated resource, or 204 with no body. PUT may return 201 if it created the resource.

Can PUT create a resource?

Yes, if the API allows it and the client knows the resource's URL — it then returns 201. Otherwise POST is used for creation.

Can GET create a resource?

It shouldn't — GET must be safe. Use POST to create.

How do you test PUT idempotency?

Send the same PUT request several times and confirm the resource ends in the same state each time, with no duplicates.

Related

• The Complete API Testing Tutorial
• The Complete REST Assured Tutorial
• HTTP Status Codes Cheat Sheet
• Top 30 API Testing Interview Questions