Headers & Content Negotiation
Run curl against one report URL twice, change the single line naming which format you will take back, and different bytes come home each time, same address, different document, though the URL never said which.
- ▸The client ranks, the server rules: your
Acceptlist is a wishlist, and onlyq=0is binding. - ▸Ask for a type the server lacks and you rarely get an error; you get its default, with a
200. - ▸One URL now returns different bytes per caller, so a cache that forgets
Varyserves the wrong variant.
A script and a browser both fetch https://example.com/report/42, the same URL to the character, and get back two different things: the script receives a compact JSON object, the browser receives a full HTML page. Nothing in the URL chose between them. What did was a single request header the script and the browser each sent without thinking about it, the Accept header, naming which media types the sender is willing to take back.
That one line is how a client asks for a representation: one particular form of the resource's data, the report as application/json or the same report as text/html. A resource is not a file; it is a thing that can be handed over in several forms, and /report/42 holds more than one. When the server picks a form, it stamps the choice in the response's Content-Type header, so the reply says exactly which representation crossed the wire. Swap the Accept line and resend to the identical URL: the Content-Type that comes back changes with it, and the address never moved.