When should an API request use GET rather than POST?

Start with what you want the server to do. Use GET to retrieve a representation of a resource. The URL and its query parameters can identify the data you want. For example, GET /products?category=books asks for product data in the books category. GET is meant for retrieval, not for requesting a change, and a GET request should not contain a body. [S1]

Use POST when you send data for the server to process. For example, POST /orders with an order body can submit order data. Processing may change state or have another effect, such as adding a resource. [S2]

In short: retrieve data → GET; send data for processing → POST. Then check that the endpoint’s documentation supports your choice.

Right: the important distinction is the operation, not just whether the request contains information.

• GET — retrieval: Requests a representation of a resource. Query parameters can specify what to retrieve, as in GET /products?category=books. HTTP classifies GET as safe and idempotent. [S1]
• POST — processing: Sends data for the server to process. That processing may change state or have another effect. HTTP does not classify POST as safe or idempotent by default. [S2]

Here, “safe” means GET is defined for retrieval rather than for requesting a change. “Idempotent” means repeating the same request has the same intended effect as making it once. Those are general HTTP semantics; they don’t establish exactly what any particular API endpoint does.

If the endpoint retrieves results and its API documentation supports that design, GET is a reasonable fit. The search term could be a query parameter, for example GET /products?search=notebook. That matches the general pattern of using query parameters to identify the data being requested. [S1]

Don’t decide from the word “search” alone. Check the API’s documented method, parameter names, and behavior. The general HTTP semantics don’t specify how a particular search endpoint works or what parameters it accepts. If the endpoint is documented to accept data for processing using POST, follow that documented convention.

Use this decision guide:

1. Describe the operation: are you retrieving data, or sending data for processing?
2. For retrieval, check whether the API documents GET and the query parameters to use. GET is not meant for requesting a change. [S1]
3. For submitted data, check whether the API documents POST and what processing it performs. [S2]
4. Before repeating a POST, check the endpoint documentation. POST is not idempotent by default, so an identical repeat may have additional effects. [S2]
5. If the API’s documented method differs from the general pattern, follow its documentation.

For example, an API might document GET /products?category=books to retrieve products and POST /orders with an order body to submit order data. These hypothetical requests illustrate the distinction; the API documentation determines the behavior of real endpoints.