Back to all posts

Why and How to Use a POST Request to Fetch Data

techapihttpgetpost

When building applications, you're taught that a GET request is for fetching data and a POST request is for changing it. This is the fundamental convention of HTTP methods and RESTful API design. However, there are specific, practical scenarios where you need to use a POST request to simply ask for data, without creating or updating a thing. Let's break down why this anti-pattern is sometimes the right solution.

What are POST and GET anyway?

In the world of web APIs, GET and POST are HTTP methods, or "verbs," that define the action you want to perform.

  • GET: Used to request data from a specified resource. Think of it as asking a question.
  • POST: Used to send data to a server to create or update a resource. Think of it as submitting a form.

The data for a GET request is sent in the URL's query string (e.g., ?id=123&category=tech). A POST request sends its data in the request's body. This distinction is key.

So, why use POST to get data?

Using POST for a read-only operation usually comes down to one of two reasons:

  1. Complex Queries: GET requests have their parameters in the URL. This can be a problem when your query is very complex, involving nested objects or long lists of IDs. URLs have a length limit (which varies by browser and server, but it's a real constraint), and stuffing too much into them can cause errors. A POST request, on the other hand, can carry a much larger and more complex payload in its body.

  2. Sensitive Data: While you should never send plain text passwords, sometimes the query parameters themselves might contain personally identifiable information (PII) or other sensitive data. GET requests expose this data in the URL, which gets logged in browser history, server logs, and proxy logs. POST requests hide this data within the request body, which is generally more secure as it isn't as widely logged.

A great example is the Elasticsearch _search endpoint. To query your data, you send a POST request with a JSON body describing your complex search criteria.

JavaScript Examples

Here’s how you’d do it in JavaScript using the fetch API.

Let's imagine we want to fetch articles matching a complex set of filters.

// The complex query data we want to send.
// This would be too messy or long for a URL.
const queryPayload = {
    filters: {
    tags: ["tech", "javascript"],
    authorIds: [101, 205, 303],
    publishedAfter: "2025-01-01"
    },
    sortBy: "date",
    sortOrder: "desc"
};

// The API endpoint we're querying.
const url = 'https://api.example.com/articles/search';

// Making the POST request with fetch.
fetch(url, {
    method: 'POST', // We explicitly use the POST method.
    headers: {
    'Content-Type': 'application/json', // Tell the server we're sending JSON.
    },
    body: JSON.stringify(queryPayload), // The payload is sent in the body.
})
.then(response => {
    if (!response.ok) {
    throw new Error(`HTTP error! Status: ${response.status}`);
    }
    return response.json(); // Parse the JSON response from the server.
})
.then(data => {
    console.log('Successfully fetched articles:', data);
})
.catch(error => {
    console.error('Error fetching data:', error);
});

Keep it Semantic

While using POST for queries is a practical solution for certain problems, it's an exception, not the rule. It breaks the "semantic" meaning of HTTP verbs—the idea that GET should be safe and idempotent, while POST is not.

What does idempotent mean? An idempotent operation is one that doesn't cause side effects on the server, no matter how many times you call it. The response might change (because other things happen on the server), but your request itself doesn't modify anything.

For HTTP requests:

  • GET /api/users - You might get different users each time if someone else adds new users, but your GET request didn't cause those changes. No side effects from your request.
  • POST /api/users - Each call creates a new user. Your request directly causes changes! Not idempotent.

When you use POST for queries, you're signaling to browsers, caches, and other systems that "this might have side effects," even when it doesn't. This can prevent caching and cause browsers to show "are you sure you want to resubmit?" warnings.

When you can, stick to GET for fetching data. It keeps your API predictable and easy to understand. But when you hit the limits of a URL, know that using POST is a valid and widely-used tool in your back pocket.

sam