HTTP Methods

Prev Next

The previous lesson mentioned that REST expresses "what you want to do" as an HTTP method rather than baking it into the URL. This lesson goes deep on the five methods you'll use constantly: GET, POST, PUT, PATCH, and DELETE. Knowing exactly what each one is supposed to do is what lets you spot a bug when the API does something different.

GET — Read Data, Change Nothing

GET asks the server to return a resource. It should never create, modify, or delete anything — a well-behaved API guarantees you can send the same GET a thousand times and the data on the server stays exactly the same.

GET https://api.recipebox.example.com/recipes/42

As a tester: if you ever see a GET request that changes data (say, a "view count" bumping a field that other endpoints depend on in an unsafe way, or worse, a GET that deletes something because someone wired up a link carelessly), that's worth flagging — it breaks a basic REST expectation.

POST — Create Something New

POST asks the server to create a new resource, usually by sending its data as a JSON body. The server decides the new resource's id and returns it.

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

{
  "title": "Masala Chai",
  "category": "Beverage",
  "prepMinutes": 10
}

As a tester: sending the exact same POST body twice should normally create two separate recipes with two different id values — that's expected, not a bug. That's the key difference from the methods below.

PUT — Fully Replace a Resource

PUT asks the server to replace an entire existing resource with the body you send. Every field the resource has should be included — any field you omit is typically reset (often to null or a default), because you're saying "this is now the complete state of this recipe," not "here's one field to change."

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

{
  "title": "Paneer Butter Masala (Restaurant Style)",
  "ingredients": ["paneer", "tomato puree", "cream", "butter", "cashew paste"],
  "steps": ["Saute the paneer", "Simmer the gravy with cashew paste", "Combine and serve"],
  "photoUri": "https://cdn.recipebox.example.com/img/42.jpg",
  "category": "Dinner",
  "prepMinutes": 25,
  "isPublished": true
}

PATCH — Partially Update a Resource

PATCH asks the server to change only the fields you include, leaving everything else on the resource untouched.

PATCH https://api.recipebox.example.com/recipes/42

{
  "prepMinutes": 25
}

As a tester: this is a very common source of real bugs. A correct PATCH implementation touches only prepMinutes here — always verify with a follow-up GET that title, ingredients, and every other field are unchanged. Many bugs are "PATCH accidentally behaves like PUT."

DELETE — Remove a Resource

DELETE asks the server to remove the resource at that URL.

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

Idempotency: Why It Matters When You Test

A method is idempotent if sending the exact same request multiple times has the same effect on the server as sending it once. This isn't academic trivia — it directly shapes what you should assert when you retest a request (which happens constantly with flaky networks, retried requests, or a tester double-clicking Send):

Method	Idempotent?	Why It Matters for Testing
GET	Yes	Repeating it should return the same data (assuming nothing else changed it) and never has side effects.
PUT	Yes	Sending the same full replacement body twice should leave the resource in the same end state both times — no duplicate resources.
DELETE	Yes	Deleting an already-deleted resource should not error in a surprising way — a well-designed API returns a consistent, predictable response (often 404) rather than crashing.
PATCH	Not guaranteed	Depends on what the patch does — `"prepMinutes": 25` is idempotent, but `"prepMinutes": prepMinutes + 5` (an increment) is not. Worth testing explicitly.
POST	No	Each call is expected to create a new resource — repeating it deliberately creates duplicates. If a "Retry" button in a real app fires a duplicate POST, you can end up with duplicate recipes, which is a classic real-world bug this idea explains.

RecipeBox Endpoint Reference

Endpoint	Method	Purpose
`/recipes`	GET	List all recipes
`/recipes/{id}`	GET	Get one recipe by ID
`/recipes`	POST	Create a new recipe
`/recipes/{id}`	PUT	Fully replace a recipe
`/recipes/{id}`	PATCH	Partially update a recipe
`/recipes/{id}`	DELETE	Delete a recipe

Note: Some older or more restrictive APIs only support GET and POST and tunnel the others through query parameters or headers. RecipeBox, like most modern REST APIs, supports all five verbs natively — that's what you should expect to test against by default.

Up next: Every one of these requests comes back with a status code. Head to HTTP Status Codes to learn what each number actually promises, and which ones testers check most.

Prev Next