POST, PUT & DELETE Requests

Prev Next

The last lesson only read data. Now let's change it: create a new RecipeBox recipe with POST, fully replace it with PUT, and remove it with DELETE — checking the response at every step, since each of these three methods has a different "correct" response shape to verify.

Sending a POST with a JSON Body

Open a new request tab, set the method dropdown to POST.
Enter the URL: https://api.recipebox.example.com/recipes
Click the Body tab, select raw, then pick JSON from the format dropdown on the right (it defaults to Text). This is what tells Postman to send the right Content-Type header automatically.
Type the new recipe as JSON:

POST https://api.recipebox.example.com/recipes

{
  "title": "Masala Chai",
  "ingredients": ["tea leaves", "milk", "sugar", "cardamom"],
  "steps": ["Boil milk and water", "Add tea leaves and spices", "Simmer and strain"],
  "category": "Beverage",
  "prepMinutes": 10,
  "isPublished": false
}

Click Send.

Checking the 201 Created Response

A correct create endpoint responds with 201 Created — not 200 — and the body echoes back the full resource, now including a server-assigned id it didn't have before:

// Response — 201 Created
{
  "id": 57,
  "title": "Masala Chai",
  "ingredients": ["tea leaves", "milk", "sugar", "cardamom"],
  "steps": ["Boil milk and water", "Add tea leaves and spices", "Simmer and strain"],
  "photoUri": null,
  "category": "Beverage",
  "prepMinutes": 10,
  "isPublished": false
}

Note: We never sent photoUri in the request body, and the server filled it in as null. That's expected — but worth explicitly checking. A common real bug is a create endpoint that omits a field entirely from the response instead of returning it as null or a sensible default, which can break a client that expects the key to always be present.

Fully Replacing It with PUT

Recall from the HTTP Methods lesson that PUT replaces the whole resource — every field must be included, or it's lost. Let's update recipe 57 to mark it published and give it a photo:

PUT https://api.recipebox.example.com/recipes/57

{
  "title": "Masala Chai",
  "ingredients": ["tea leaves", "milk", "sugar", "cardamom"],
  "steps": ["Boil milk and water", "Add tea leaves and spices", "Simmer and strain"],
  "photoUri": "https://cdn.recipebox.example.com/img/57.jpg",
  "category": "Beverage",
  "prepMinutes": 10,
  "isPublished": true
}

The response is 200 OK with the updated resource. If we had left out ingredients from this body entirely, a strictly correct PUT implementation would wipe it out — send a follow-up GET /recipes/57 afterward to confirm nothing you didn't intend to change actually changed.

Deleting It

DELETE https://api.recipebox.example.com/recipes/57

The typical, correct response is 204 No Content — an empty body, because there's nothing left to describe. Two follow-up checks are worth making a habit of:

Send GET /recipes/57 again — it should now return 404 Not Found, proving the delete actually took effect.
Send the exact same DELETE a second time — per the idempotency discussion earlier in this track, it shouldn't crash the server; a well-behaved API returns a consistent 404 for deleting something that's already gone.

A Note on the Content-Type Header

Every request with a JSON body needs a Content-Type: application/json header so the server knows how to parse the body. When you pick JSON in the Body → raw format dropdown, Postman sets this header for you automatically — you'll see it appear (greyed out, auto-generated) in the Headers tab. You can override it manually if you're deliberately testing how the API reacts to a missing or wrong Content-Type (a legitimate negative test), but for normal requests, let Postman handle it.

Up next: Rebuilding these requests from scratch every time doesn't scale. Head to Postman Collections to organize them into a reusable RecipeBox API collection.

Prev Next