How to Test a REST API Online
Last updated 2026-09-17
Testing a REST API means sending it an HTTP request and checking whether the response matches what you expect — you don't need to install anything to do this; a browser-based REST client works for most everyday cases.
Pick the right method
GET reads data and has no body. POST creates something new. PUT replaces a resource entirely; PATCH updates part of it. DELETE removes it. Using the wrong method against a working endpoint is a common source of confusing 404 or 405 errors.
Set the headers the API expects
Most JSON APIs expect a Content-Type: application/json header on any request with a body, and many require an Authorization header (often Bearer <token>) for anything beyond public read endpoints.
Send the request and read the status code first
2xx means success, 3xx a redirect, 4xx a problem with your request (400 bad input, 401/403 auth, 404 wrong URL), 5xx a problem on the server's side that you generally can't fix from the client.
Check the response body and timing
A JSON body pretty-printed is much easier to scan than a single line of raw text. Response time matters too — a request that suddenly takes seconds instead of milliseconds often signals a server-side problem worth reporting.
Example
Testing GET https://jsonplaceholder.typicode.com/todos/1 (a public test API) returns a 200 OK with a small JSON object in well under a second — a good sanity check that a REST client is working correctly before pointing it at a real API.
Important Considerations
- A browser-based REST client is subject to CORS: if the target API doesn't send an Access-Control-Allow-Origin header permitting requests from the page you're on, the browser blocks you from reading the response, even though the request technically reached the server. A desktop tool like Postman or curl doesn't have this restriction because it isn't running inside a browser.
- Never paste real production API keys or tokens into a REST client running on someone else's website unless you've verified, as here, that requests are sent directly from your browser to the target and never touch that site's own servers.
- A 401 means you're not authenticated at all (missing or invalid credentials); a 403 means you are authenticated but not allowed to do this specific thing — they're easy to confuse but call for different fixes.
Frequently Asked Questions
- Why do I get a network error instead of a real response?
- The three usual causes are: the target API doesn't allow cross-origin browser requests (CORS), the URL is wrong or unreachable, or you're calling a plain http:// API from a page loaded over https:// (browsers block this as mixed content).
- Can I test an API that requires authentication?
- Yes, as long as you can add the required header (commonly Authorization: Bearer <token> or an API-key header) — just be cautious about where you paste real credentials, and prefer a test/sandbox token when the API offers one.