How to Test REST APIs in Your Browser — A Developer's Guide

What is API Testing?

Every modern web and mobile application runs on APIs. When you load your Twitter feed, place an order on Amazon, or check the weather on your phone, an API call is happening behind the scenes. API testing is the practice of sending requests to those endpoints and verifying that the responses are correct — the right status code, the expected data shape, and reasonable performance.

Unlike UI testing, API testing targets the layer beneath the interface. It catches bugs earlier, runs faster, and covers scenarios that are difficult to trigger through a browser click. Whether you are building your own API or integrating with a third-party service, knowing how to test endpoints quickly is a fundamental developer skill.

HTTP Methods Explained

REST APIs use standard HTTP methods to indicate the action being performed on a resource. Here is a quick reference:

Key distinction: PUT replaces the entire resource — any fields you omit will be removed. PATCH only updates the fields you include in the request body. Most APIs that accept updates use PATCH for partial modifications and PUT for full replacements.

How to Test APIs in Your Browser

You do not need to install Postman or memorize cURL flags to test an API. The API Explorer on JSONTech.net lets you send requests directly from your browser. Here is how:

1. Open the API Explorer tool.
2. Select the HTTP method (GET, POST, PUT, PATCH, or DELETE) from the dropdown.
3. Enter the endpoint URL. For example: https://jsonplaceholder.typicode.com/posts/1
4. Add any headers you need (like Content-Type or Authorization).
5. If the method requires a body (POST, PUT, PATCH), type your JSON payload in the body editor.
6. Hit Send and inspect the response — status code, headers, and the formatted JSON body.

Example: Fetching a Post

GET https://jsonplaceholder.typicode.com/posts/1

Response (200 OK):
{
  "userId": 1,
  "id": 1,
  "title": "sunt aut facere repellat provident occaecati excepturi optio reprehenderit",
  "body": "quia et suscipit\nsuscipit recusandae consequuntur..."
}

Example: Creating a Post

POST https://jsonplaceholder.typicode.com/posts
Content-Type: application/json

{
  "title": "My New Post",
  "body": "This is the content of my post.",
  "userId": 1
}

Response (201 Created):
{
  "id": 101,
  "title": "My New Post",
  "body": "This is the content of my post.",
  "userId": 1
}

Understanding Request Headers

Headers carry metadata about the request. They tell the server what format you expect, who you are, and how the connection should behave. Here are the ones you will use most often:

Forgetting Content-Type: application/json on POST/PUT requests is one of the most common reasons APIs return 400 Bad Request. The server does not know how to parse the body without it.

Authentication Methods

Most production APIs require authentication. The three patterns you will encounter most:

Bearer Token (JWT)

The most common approach for modern APIs. You include a token in the Authorization header:

{
  "headers": {
    "Authorization": "Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c",
    "Content-Type": "application/json"
  }
}

Basic Authentication

Encodes the username and password as a Base64 string. Simple but only safe over HTTPS:

{
  "headers": {
    "Authorization": "Basic dXNlcm5hbWU6cGFzc3dvcmQ=",
    "Content-Type": "application/json"
  }
}

API Key

Some APIs use a custom header or query parameter for a static key:

// As a header
{
  "headers": {
    "X-API-Key": "sk_live_abc123def456"
  }
}

// As a query parameter
GET https://api.example.com/data?api_key=sk_live_abc123def456

Reading API Responses

When you send a request, the response tells you exactly what happened. You need to read three things: the status code, the response headers, and the body.

Status Codes

Response Headers

Pay attention to headers like Content-Type (confirms the response format), X-RateLimit-Remaining (how many requests you have left), and Retry-After (when to try again after hitting a rate limit).

JSON Body

The response body is where your data lives. A well-designed API wraps it in a consistent structure:

{
  "data": {
    "id": 42,
    "name": "Widget",
    "price": 9.99
  },
  "meta": {
    "request_id": "req_8f3a2b"
  }
}

When something goes wrong, you get an error object instead of a data object. Always check the status code first, then parse the body accordingly.

CORS: What It Is and Why You See Errors

Cross-Origin Resource Sharing (CORS) is a browser security mechanism. When your JavaScript running on localhost:3000 tries to call an API on api.example.com, the browser blocks the request unless the server explicitly allows it via CORS headers.

The typical error looks like:

Access to fetch at 'https://api.example.com/data' from origin
'http://localhost:3000' has been blocked by CORS policy: No
'Access-Control-Allow-Origin' header is present on the requested resource.

This is not a bug in your code — it is the browser enforcing security. The fix has to come from the server side. Common workarounds:

• Ask the API owner to add your origin to their Access-Control-Allow-Origin header.
• Use a proxy — route requests through your own backend (e.g., a Next.js API route or a simple Express server) to avoid the cross-origin restriction entirely.
• Use a browser-based tool like the API Explorer, which can send requests from the server side and bypass CORS limitations for testing purposes.

CORS only affects browsers. Tools like cURL, Postman, and server-side code are not subject to CORS restrictions — they do not run inside a browser sandbox.

Common API Testing Mistakes

These are the pitfalls that trip up developers — from beginners to experienced engineers switching to unfamiliar APIs:

1. Forgetting the Content-Type header. Sending a JSON body without Content-Type: application/json causes most servers to reject or misparse the request.
2. Using GET when you mean POST. GET requests should never have a body. If you are sending data, you need POST, PUT, or PATCH.
3. Ignoring status codes. A 200 with an error message in the body is not a success. Always check the actual HTTP status code.
4. Hardcoding credentials in the URL. Never put API keys or tokens in the query string if headers are an option — URLs end up in server logs, browser history, and referrer headers.
5. Testing only the happy path. Send malformed JSON, empty bodies, missing required fields, and invalid tokens to see how the API actually handles errors.
6. Not checking rate limits. Many APIs return a 429 status code when you exceed the limit. Check X-RateLimit-Remaining headers proactively.
7. Confusing CORS errors with server errors. A CORS error means the browser blocked the request — the server may have responded successfully but the browser refused to show you the result.

Try It Yourself