REST API Tester

Testing REST endpoints the resource-oriented way

REST is not simply "JSON over HTTP". Its defining idea is that a server exposes resources — an order, a user, a repository — each addressable by a stable URL, and that the HTTP verb you choose is what declares your intent toward that resource. A REST API tester is therefore most useful when you stop thinking in terms of "calling a function" and start thinking in terms of "acting on a noun". The URL names the noun; the method is the verb; the body is the proposed new state.

That framing changes how you test. Rather than firing one request and declaring victory, you walk a resource through its lifecycle and check that each transition reports itself honestly. Create it, read it back, modify part of it, replace it wholesale, then remove it — and at every step confirm that the status code, the response headers and the body agree with one another. Most integration bugs surface in that disagreement: a body that says the update succeeded next to a status code that says it did not, or a 204 No Content that arrives with a content body attached anyway.

A full CRUD walkthrough

1. Create. Set the method to POST and target the collection URL, not an item URL — /v1/orders, never /v1/orders/new. Add Content-Type: application/json in the Headers tab and put your payload in Body. Expect 201 Created plus a Location header naming the resource that now exists.
2. Read. Copy that Location value into the URL bar with the method on GET. The representation you get back should match what you sent, plus any server-assigned fields such as identifiers and timestamps. Discrepancies here usually mean the API silently dropped a field it did not recognise.
3. Update. Switch to PATCH and send only the fields you intend to change. Then try the same operation as a PUT with a deliberately incomplete body — a strict REST implementation should either reject it or blank the omitted fields, and finding out which is a genuinely valuable five seconds of testing.
4. Delete. Send DELETE to the item URL, expect 204 No Content, then immediately GET the same URL again. A 404 confirms the deletion took effect; anything else suggests caching or a soft-delete you were not told about.

Because every request you send is recorded in the History tab, stepping backward and forward through that sequence takes a click rather than a retype. The full semantics of each verb — which are safe, which are idempotent, which may carry a body — are set out in our reference guide to HTTP methods.

Idempotency, safety and why they matter in testing

Two properties govern how a REST client may retry your request. A safe method promises not to change server state at all: GET, HEAD and OPTIONS qualify. An idempotent method may change state, but sending it five times leaves the resource in the same condition as sending it once — true of PUT and DELETE, and false of POST.

These are not academic labels. Proxies, load balancers and HTTP client libraries actively rely on them: many will silently retry an idempotent request after a network timeout, and will refuse to retry a POST. If your API implements PUT in a way that is not actually idempotent — by appending to a list, say, rather than replacing it — a single dropped packet in production becomes duplicated data. Testing for this is trivial with a tester: send the identical PUT twice in a row, then GET the resource and see whether anything doubled.

Reading the response like a diagnostician

Check the status class before the body. 2xx means the server accepted the request, 3xx means the resource lives elsewhere, 4xx blames your request and 5xx admits the server broke. The most commonly misread pairing is 401 Unauthorized versus 403 Forbidden: the first means the server does not know who you are, the second means it knows exactly who you are and has decided you may not do this. Sending credentials again fixes only the former.

Then read the response headers, which explain a surprising share of confusing behaviour. A Content-Type of text/html where you expected JSON usually means a gateway or login page intercepted the call before your API ever saw it. Rate-limit headers such as X-RateLimit-Remaining and Retry-After explain intermittent 429 responses. ETag and Cache-Control explain why a resource you just updated still looks stale. Our guide to HTTP headers covers what each one is asking of you, and the complete HTTP status code reference decodes anything unfamiliar.

Query parameters, pagination and content negotiation

Collection endpoints rarely return everything at once. Filtering, sorting and pagination almost always arrive as query parameters, and getting their encoding right by hand is fiddly — spaces, commas, nested brackets and unicode all need escaping. Entering them as name/value pairs in the Params tab hands that problem to the tester, which appends and encodes them for you when the request goes out.

Pagination styles vary, and it is worth confirming which one an unfamiliar API uses before you write a client loop. Offset pagination takes page and per_page and is simple but drifts when rows are inserted mid-traversal. Cursor pagination returns an opaque token to feed into the next call and stays stable under concurrent writes. Link-header pagination puts the next URL in a Link response header, which the response pane shows you directly. Send one request and the answer is visible.

Content negotiation is worth an experiment too. Send an Accept header of application/xml to a JSON API and note what happens: a strict implementation returns 406 Not Acceptable, while a lenient one shrugs and sends JSON anyway. Neither is wrong, but knowing which you face determines whether your production client can safely rely on the header. Similarly, an OPTIONS request reveals the allowed methods and the CORS policy for an endpoint before you spend an afternoon debugging a browser preflight failure.

Authentication schemes you will meet

Most REST APIs authenticate in one of four ways, and all four are covered in the Auth tab. Bearer tokens are the default for OAuth 2.0 and modern platform APIs; the token is often a JWT, and if a request is rejected the first thing to check is whether it has simply expired — paste it into the JWT decoder to read its exp claim without trusting the token's issuer. Basic auth is still common for internal services and webhook receivers, and is just a Base64 encoding of username:password. API key headers use a vendor-specific name such as X-API-Key. Occasionally a key is expected as a query parameter instead, which belongs in the Params tab rather than Auth.

When a request finally works, the Copy as cURL button reproduces it exactly — method, headers, auth and body — as a shell command you can paste into a script, a CI job, a bug report or a message to whoever maintains the API. That is usually the fastest way to prove a problem is on the server side rather than in your client.

Note: requests are sent from our proxy rather than your machine, so loopback and private network addresses are blocked. Expose a development API on a public URL with a tunnelling service before testing it here.

Related tools and references

REST API testing FAQ