Source: https://uptimeify.io/resources/platform-and-support/glossary/http-query

# HTTP QUERY

> QUERY is an HTTP method that is safe and idempotent like GET but passes its input as a request body, so a read-only query does not have to fit into the URL.

It sits exactly between the two methods everyone already uses: it reads like GET and changes nothing on the server, and it carries content like POST. The difference to POST is not the wire format but the promise. A QUERY request states that it only reads.

## The problem it solves

Until QUERY existed, a read that needed a body had one option: POST. A search with two dozen filters, a GraphQL document, an analytics query with a nested time range, none of them fit into a URL that proxies, servers and browsers will still accept, so they went out as a POST.

That worked, and it lied. POST tells every layer in the path that the request changes something. The consequences are practical, not academic:

- The response is not cacheable in the way a read should be, because the cache key is the URI and the body is invisible to it.
- Proxies, gateways and web application firewalls classify the request as a write and apply write rules to it.
- An automatic retry after a timeout is no longer harmless, because nothing in the request says it is safe to repeat.

QUERY removes the lie. Same body, honest semantics.

## GET, POST and QUERY side by side

| | Safe | Idempotent | Request body | Cacheable |
|---|---|---|---|---|
| GET | yes | yes | no defined meaning | yes, key is the URI |
| POST | no | no | yes | only with explicit cache directives |
| QUERY | yes | yes | yes | yes, key includes the body |

The last cell is the one that matters most in practice. RFC 10008 requires a cache key for QUERY to incorporate the request content, which is what makes a cached read with a body possible at all.

## Where QUERY shows up

Searches with long filter sets. GraphQL endpoints, which have been described as POST for years while doing nothing but reading. Analytics and reporting APIs whose parameters outgrow the URL length limits of intermediaries. Anything that answers a question instead of changing an answer.

## Standardisation

QUERY is specified in [RFC 10008](https://www.rfc-editor.org/rfc/rfc10008.html), "The HTTP QUERY Method", published in June 2026 as a Proposed Standard on the IETF standards track. It grew out of the httpbis working group draft known as "safe method with body". Server and framework support is arriving gradually, which is why a target that does not implement the method answers with `405 Method Not Allowed`, one of the [HTTP status codes](/resources/platform-and-support/glossary/http-status-code) worth watching for.

## What it means for monitoring

A monitor that checks a search endpoint with POST reports on a request nobody makes in production, and it may trip the same write-path rules a real user never touches. With QUERY the check describes the endpoint it is checking. In Uptimeify, QUERY sits in the method picker of every HTTP monitor next to GET, with the same body field POST gets, so [uptime monitoring](/monitoring/website-monitoring/uptime-monitoring) covers query endpoints as they are actually built.