API & webhooks

REST API Calls Example: Create, Read, Replace and Delete

Follow a synthetic resource through POST, GET, PUT and DELETE; verify response contracts, replacement behavior, repeated deletion and partial failures.

By Uddhav Gopani, FounderPublished 27 September 2026Updated 29 September 2026

Follow one identifier through a complete fixture

A sequence of REST-style API calls is easier to verify when each request refers to the same resource. This example uses a fictional notes service with a documented creation, retrieval, replacement and deletion contract. Run the exercise against a disposable local fixture or an authorized test environment.

Do not hardcode a production identifier into a tutorial that ends with DELETE. Save the identifier returned by the creation response and use that exact value for the remaining calls. If creation fails, stop the sequence rather than borrowing an older identifier from the interface.

Specify the expected transition for every request

Request	Example body	Expected fixture response
POST /notes	{"title":"First map"}	201 with a new string id and that title
GET /notes/{id}	No body	200 with the newly created note
PUT /notes/{id}	{"title":"Revised map"}	200 with the replacement title
GET /notes/{id}	No body	200 with Revised map
DELETE /notes/{id}	No body	204 with no response body
GET /notes/{id}	No body	404 because this fixture removed the note

These statuses are the fixture's explicit contract, not a promise that every API uses exactly the same responses. A service can document asynchronous processing or a different successful representation. Adapt assertions to that service while preserving meaningful checks.

Check creation before attempting the next operation

Send a serialized JSON body with the documented media type. After the POST, verify the creation status and parse the returned identifier. The identifier's type matters: treating a string with meaningful formatting as a number can change it before the next request.

A readable response with an unexpected title should fail the fixture assertion. Do not consider the POST verified solely because the status was 201. Confirm that the new resource corresponds to the submitted values.

Encode the returned identifier according to the documented path grammar before constructing later URLs. Do not concatenate a value containing a slash or query delimiter into a different route accidentally.

Understand replacement before using PUT

The PUT reference describes replacement semantics. An API's writable representation determines which fields belong in the request. Do not assume that sending one field preserves every omitted field unless the service explicitly defines that behavior.

This fixture has only one writable title field, so its replacement example is intentionally small. A more complex note with tags or sharing settings needs a correspondingly complete request contract. A partial-update operation may use PATCH with its own media type and rules.

Follow the replacement with a GET. That read verifies persistence at the resource boundary and detects a server that merely echoed the submitted title without updating its stored representation. If the service is eventually consistent, use its documented consistency model rather than adding arbitrary sleeps.

Interpret a bodyless and repeated deletion

A 204 response must be handled without JSON parsing. After deletion, the fixture's GET returns 404. The DELETE reference explains the method, but the service still defines which deletion responses it exposes.

A second DELETE can return 404 while the operation remains idempotent in its intended resource effect: the resource stays absent. Idempotency does not require every repeated response status or body to be identical.

Stop and identify the failing stage

If replacement returns a validation error, do not continue as though Revised map was saved. Record the last confirmed state and the failed request. Cleanup should target only the disposable resource created for this exercise, under the fixture's rules.

The REST API Testing Tool can send each authorized request and display its readable response. It does not orchestrate this lifecycle or decide which identifier is safe to delete. Keep that sequencing in your test and verify the exact state after each step.