Query strings and request bodies

HTTP gives you two main places to send input: the query string in the URL, and the body after the headers.

A query string starts with ? and uses & between pairs:

/blog/?tag=astro&page=2

Query strings shine for filters, search terms, sorting, and pagination. They show up in the address bar, so users can bookmark or share the exact view. Servers parse them from the request target on the first line.

A body carries data separately from the URL:

{
  "title": "Learn HTTP",
  "published": true
}

Bodies are common with POST, PUT, and PATCH. The Content-Type header tells the server how to decode the bytes (application/json, application/x-www-form-urlencoded, multipart for file uploads).

Choose based on semantics and size, not convenience. Reading data belongs in query parameters on a GET. Creating or updating a resource usually belongs in a body on POST or PATCH.

Never put secrets in a query string. URLs land in browser history, server access logs, analytics tools, and sometimes the Referer header on the next request. HTTPS encrypts the URL on the wire, but it does not stop your laptop or your logging pipeline from storing it.

Test both forms with curl:

curl -i 'https://httpbin.org/get?tag=astro&page=2'

The JSON response includes an "args" object with your query parameters.

curl -i https://httpbin.org/post \
  -H 'Content-Type: application/json' \
  -d '{"title":"Learn HTTP","published":true}'

The echoed "json" field shows the body parsed as JSON. Same server, different slot for input.

Large payloads belong in the body, not the query string. URLs have practical length limits in proxies and logs. File uploads use multipart/form-data in the body with a boundary marker in Content-Type.

Try this on your own project: find one list page that filters via the query string and one form that POSTs JSON. Trace where each parameter is read on the server.