POST, PUT, PATCH, DELETE Requests

GET reads. The other four verbs write. POST creates a resource, PUT replaces one, PATCH edits part of one, and DELETE removes it. You learned the theory in the HTTP Methods, Status Codes, and Headers lesson — this lesson is about driving each verb through Postman, with a real request body, against JSONPlaceholder. By the end you'll have run a full CRUD cycle.

POST — create a new resource

Open a fresh tab and switch the method dropdown from GET to POST. Set the URL:

https://jsonplaceholder.typicode.com/posts

Now the tab below the URL bar matters: click Body. You'll see a row of radio buttons — none, form-data, x-www-form-urlencoded, raw, binary, GraphQL. Pick raw. A second dropdown appears on the right showing Text — change it to JSON. Postman now knows you're sending JSON and will set Content-Type: application/json automatically.

Paste this into the body editor:

{
  "title": "My First Postman Post",
  "body": "Created from the Postman Course",
  "userId": 1
}

Click Send. The response should be:

{
  "title": "My First Postman Post",
  "body": "Created from the Postman Course",
  "userId": 1,
  "id": 101
}

Status: 201 Created. The server echoed your fields back and added a generated id. (JSONPlaceholder is a fake — it doesn't actually persist anything — but the shape of the response is exactly what a real API returns.)

POST is not idempotent. Click Send three more times. You'll get back four "created" responses, each with id: 101 (because the API is faking it; a real one would assign 102, 103, 104). On a real backend, four POSTs equal four new rows in the database.

PUT — replace an entire resource

Change the method to PUT and the URL to https://jsonplaceholder.typicode.com/posts/1. PUT requires you to identify which resource you're replacing — that's why the URL ends in /1.

The body should contain the complete resource, every field included:

{
  "id": 1,
  "title": "Updated Title",
  "body": "Updated body. PUT replaces every field.",
  "userId": 1
}

Send. You get 200 OK with the new representation. The key thing: PUT means replace. If you'd left body out of the request, a strict API would set it to null or remove it. PUT is total replacement.

PUT is idempotent. Send the exact same request three times — the resource ends up in the same state as after the first call. That's the whole point of PUT versus POST.

PATCH — update only specific fields

Change the method to PATCH and keep the same URL https://jsonplaceholder.typicode.com/posts/1. The body now contains only what you want to change:

{
  "title": "Just the title changed"
}

Send. Response: 200 OK with the merged resource — title updated, body and userId untouched. PATCH is the verb you'll use most for edit operations in real APIs because it doesn't require sending fields you don't want to touch.

PATCH is usually idempotent if the API is well-designed (running it twice produces the same end state).

DELETE — remove a resource

Change the method to DELETE and keep https://jsonplaceholder.typicode.com/posts/1. The Body tab should be set to none — DELETE requests don't carry a body. Send. JSONPlaceholder returns 200 OK with an empty {}. A real API typically returns 204 No Content (success, no body to deliver).

DELETE is idempotent. The first call removes the resource; the second one finds nothing to remove and (if the API is well-designed) returns 404 Not Found. The state — "this resource is gone" — is the same after one call or ten.

The CRUD cycle, drawn

These four verbs, together with GET, form the Create, Read, Update, Delete cycle that every REST API exposes. Walking through it once cements the verb-to-status-code mapping:

That's a complete lifecycle of one resource: create, read, update, delete, confirm. Five Postman requests, five expected status codes, no surprises. When you build a test collection later (Chapter 5), this is exactly the shape it will take.

PUT vs PATCH — the gotcha

The distinction trips up almost every newcomer. Walk a concrete example:

The current resource on the server:

{ "id": 1, "title": "Original", "body": "Original body", "userId": 1 }

You PUT this:

{ "id": 1, "title": "New title" }

A strict API treats PUT as full replacement and the resource becomes { "id": 1, "title": "New title" } — body and userId are now gone or null.

You PATCH this:

{ "title": "New title" }

The resource becomes { "id": 1, "title": "New title", "body": "Original body", "userId": 1 } — only title changed; the rest is untouched.

In practice, many APIs are lenient: they accept partial bodies on PUT and behave like PATCH. As a tester, don't rely on the lenient behaviour. Always send the whole resource on PUT and only the changing fields on PATCH. Your tests then match the spec, not the implementation's politeness.

Content-Type — set automatically (mostly)

When you pick raw → JSON, Postman adds Content-Type: application/json to the request. You can verify this on the Headers tab: a greyed-out Content-Type row marked "auto-generated". If you switch the body type to raw → Text by mistake, the server sees Content-Type: text/plain and likely rejects the request with 415 Unsupported Media Type. The 415 is a tell-tale sign your Body type dropdown is wrong.

Saving your CRUD requests

Save each request to your JSONPlaceholder Practice collection (Cmd/Ctrl+S) with descriptive names — POST Create Post, PUT Replace Post, PATCH Update Post Title, DELETE Post. You'll reuse them in Chapter 3 when we add tests.

⚠️ Common mistakes

• Forgetting to set the body type to JSON. If the body type stays at Text, Postman sends Content-Type: text/plain and most APIs return 415 Unsupported Media Type. Always pick raw → JSON.
• Sending invalid JSON. Trailing commas ({"a": 1,}), single quotes ({'a': 1}), or unquoted keys ({a: 1}) are not valid JSON. Postman highlights syntax errors in red on the body editor — fix them before sending or you'll get a 400.
• Confusing PUT with PATCH. Sending a PUT with only one field on a strict API will erase the others. When in doubt, use PATCH for edits and reserve PUT for full replacements.

🎯 Practice task

Run a full CRUD cycle. 25-30 minutes.

1. In your JSONPlaceholder Practice collection, create four new requests:
   • POST Create Post → POST /posts with a body that includes title, body, userId.
   • GET Verify Post → GET /posts/101 (the id JSONPlaceholder returns for new POSTs).
   • PATCH Update Post Title → PATCH /posts/1 with body {"title": "Patched"}.
   • DELETE Post → DELETE /posts/1 with no body.
2. Send each one in order. Record the status code for each.
3. On the POST: check the Headers tab on the request (not the response). Confirm Content-Type: application/json is auto-generated. Now switch the Body type to raw → Text and re-send. What status code comes back? Switch it back to raw → JSON.
4. Try to break the JSON: change "title" to 'title' (single quotes) and send. Postman shows a syntax warning; the server returns 400 Bad Request. Fix and re-send.
5. Send a PUT to /posts/1 with only {"title": "Half-replacement"}. Note that JSONPlaceholder is lenient — it merges. On a strict API, this would have erased body and userId. Make a mental note never to depend on lenient PUT.
6. Stretch: sign up for a free restful-booker account and run a real CRUD cycle that actually persists. POST a new booking, GET it back, PATCH a field, DELETE it, GET to confirm a real 404.

You can now drive every CRUD verb in Postman. The next lesson zooms in on the response — every panel, every tab, and what to look for when validating an API call.