Testing a REST API means sending a request and checking that the response is what the contract promised — the right status code, the right shape, and a sane response time. Here is the whole loop in SchemaClient.
1. Pick a method and a URL
Open the REST Client tab and enter the endpoint. The method matters more than people expect, because it decides what the server is allowed to do:
- GET — read something. Must not change server state.
- POST — create something, or trigger an action.
- PUT — replace a resource wholesale.
- PATCH — update part of a resource.
- DELETE — remove a resource.
2. Add headers
Most failures at this stage are header failures. The two that matter most:
Content-Type: application/json
Authorization: Bearer <your-token>
If the API returns 415 Unsupported Media Type, your Content-Type is wrong. If it
returns 401, the token is missing, expired, or in the wrong header.
3. Add a body
For POST, PUT and PATCH, switch to the Body tab and send JSON:
{
"email": "dev@example.com",
"plan": "free"
}
Malformed JSON is the second most common cause of a 400 — a trailing comma is
enough to break it.
4. Send it and read the status code
Status codes tell you who is at fault before you read a single line of the body:
- 2xx — it worked.
- 3xx — it moved. Check the
Locationheader. - 4xx — you got it wrong. Bad input, bad auth, wrong URL.
- 5xx — the server got it wrong. Your request may be fine; retry and check logs.
5. Check the response body, not just the status
A 200 OK can still be wrong. An endpoint that returns {"users": null} instead of
an empty array will pass a status-code check and break your app anyway. This is why
it is worth validating responses against a schema
rather than eyeballing them.
Save it for next time
Once a request works, save it into a collection so you are not rebuilding it by hand every week — see collections and cloud sync. If the API you are testing runs on your own machine, you will also want a public URL for localhost.