REST API Tester

DEVELOPMENT TOOLS

REST API Tester

A lightweight alternative to Postman. Test GET, POST, PUT, and DELETE requests directly from your browser. Inspect response headers, status codes, and formatted JSON bodies. Note: Subject to browser CORS restrictions.

REST APIs: The Building Blocks of the Modern Web

HTTP-based APIs are how almost every modern app talks to its backend, to third-party services, to itself across microservices. Testing them, sending requests, inspecting responses, debugging mismatches, is a daily task for backend engineers, mobile developers, and full-stack devs. This tool is a quick browser-based way to do that without installing a desktop app or running curl.

The Limitations: Why This Isn't Postman

Browsers enforce the Same-Origin Policy and CORS, a security mechanism that prevents JavaScript on one domain from arbitrarily calling APIs on other domains. By default, when JavaScript (including this tool) requests api.example.com from tools.example.org, the browser:

1. Sends a "preflight" OPTIONS request asking permission.
2. Reads the server's CORS response headers.
3. If the server didn't allow the origin/method/headers, the browser blocks the actual request and JavaScript sees a CORS error.

This is essential security, without it, any website you visit could make authenticated requests to your bank, GitHub, email, etc. on your behalf.

The downside for testing: APIs not configured for cross-origin browser access can't be tested in this tool. You'll get an error like:

When you see this: use curl, Postman desktop, or any non-browser tool. Those don't enforce CORS because they're not browsers.

For browser-friendly APIs (those that send Access-Control-Allow-Origin: * or include your origin), this tool works fine.

The HTTP Methods (Verbs)

Idempotent = same request multiple times has same effect as once. This matters for retries: idempotent calls are safe to retry on network failure; non-idempotent (POST creating an order) aren't, because a retry may create a duplicate.

The HTTP spec defines these semantics; many APIs play loose (POST that's idempotent, PATCH that's idempotent). Read the API's docs.

Status Codes

The first thing to check after a request:

Common ones to recognize:

• 200 OK, success with response body.
• 201 Created, success, resource created (often returns the new resource).
• 204 No Content, success, no body.
• 301 Moved Permanently, redirect; update bookmarks.
• 302 Found, temporary redirect.
• 304 Not Modified, cached version is still valid (with If-None-Match or If-Modified-Since).
• 400 Bad Request, malformed request; you sent bad data.
• 401 Unauthorized, missing or bad authentication credentials.
• 403 Forbidden, authenticated but not allowed to access this resource.
• 404 Not Found, resource doesn't exist.
• 405 Method Not Allowed, endpoint exists but doesn't support this verb.
• 409 Conflict, your update conflicts with current state (e.g., version mismatch).
• 422 Unprocessable Entity, semantically invalid (validation failure).
• 429 Too Many Requests, rate limited; back off.
• 500 Internal Server Error, generic server error; check their logs.
• 502 Bad Gateway, upstream service failed.
• 503 Service Unavailable, temporarily overloaded or down.
• 504 Gateway Timeout, upstream service didn't respond.

The distinction between 401 and 403 matters: 401 means "I don't know who you are"; 403 means "I know who you are and you can't access this."

Headers: The Metadata

Common request headers:

• Content-Type: format of the request body. application/json for JSON, application/x-www-form-urlencoded for form data, multipart/form-data for file uploads.
• Accept: format(s) you want the response in. application/json is most common.
• Authorization: credentials. Bearer <token> or Basic <base64>.
• User-Agent: identifies your client. Browsers set this automatically.
• Origin: the origin of the JavaScript (used by CORS).
• Referer: the URL of the page making the request (misspelled by historical accident).
• If-Match / If-None-Match: conditional requests based on ETags.

Common response headers:

• Content-Type: format of the response body.
• Content-Length: bytes.
• Cache-Control: how / how long to cache.
• ETag: a hash of the response, used for conditional GETs.
• Set-Cookie: stores a cookie in your browser.
• X-RateLimit-*: how many requests you have left.
• Access-Control-Allow-*: CORS permissions.

Authentication Patterns

Bearer tokens (most modern APIs):

The token is opaque to the client; the server validates it. Tokens are typically JWTs (signed, sometimes encrypted) or random strings looked up in a session store.

API keys (simpler, less secure):

Or in query: ?api_key=.... Query params leak into logs and browser history, prefer header form.

Basic auth (legacy):

Where dXNlcjpwYXNz is base64("user:pass"). Only sane over HTTPS (it's reversible in plain text).

OAuth 2.0 (delegated auth):

The client doesn't get the user's password; instead, an Authorization Server issues a Bearer token after the user logs in. The token is then used like any other bearer. The flow has several variants (Authorization Code, Client Credentials, etc.); the result is a Bearer token you use in the API.

Request Bodies

JSON is the dominant format:

Form data (older, for HTML form submissions):

Multipart (for file uploads):

Content-Type: multipart/form-data; boundary=... --... Content-Disposition: form-data; name="file"; filename="photo.jpg" Content-Type: image/jpeg --...--

Make sure the Content-Type matches the body. Sending JSON with Content-Type: application/x-www-form-urlencoded confuses servers.

Common Debugging Patterns

"It works in curl but not my app", usually CORS (browser-only) or Content-Type (browser sets it for you with fetch if you pass a JS object; you must set it manually for JSON strings).

"401 Unauthorized but I'm sending the token", check exact header name (Authorization not authorization for some strict servers), check Bearer prefix included, check token isn't expired, check URL is correct.

"500 Internal Server Error", server side, not your problem to fix unless you can see their logs. Check status page, retry later, contact support.

"Response is empty / weird", check Content-Type. If text/html, you're hitting a login page or error page; check authentication or URL.

"CORS preflight failed", server doesn't support OPTIONS or doesn't include required headers in Access-Control-Allow-Headers. Server-side fix needed.

"Timeout", slow server, or you're hitting an internal-only URL from outside. Check network connectivity, server health.

Caching, Conditional Requests, ETags

For efficient APIs:

ETags let the server respond with "still the same" without resending the body. Saves bandwidth on stable resources.

Rate Limits

Most public APIs limit how many requests you can make:

Respect these. Back off on 429s. Add exponential backoff with jitter for resilient clients.

Privacy

This tool sends requests directly from your browser to the URL you provide. No intermediate proxy, no analytics on the requests, no logging. Open DevTools Network during use: you'll see two requests, your test request to the target API, and nothing else from this tool. Important because:

• API tokens and keys are sensitive, sending them through a third-party proxy would leak credentials.
• Request/response bodies often contain user data, internal IDs, or proprietary structures.
• The URLs you test might reveal internal infrastructure (api.internal.company.com) that shouldn't appear in third-party logs.

Everything stays between your browser and the destination server.