About this tool
Choose whether the version sits in the path, in a header, in a query parameter or in Accept negotiation, and the tool shows the request that style actually produces. The request line and headers are written out, together with a shell command that sends the same thing. Changing the host, path, version number, header name or vendor token updates the result immediately.
Alongside that it works out the effect on caching and sharing. How many addresses point at one resource, how many cache entries exist across versions, whether a Vary response header is required and whether the address alone reproduces the result all differ by style. Distinguishing versions by header or Accept without sending Vary lets a shared cache hand the version it stored first to a client asking for another.
No style is declared the recommended one. As of October 2026 there is no authoritative recommendation, and the trade-off turns on where your caches sit and how much control you have over clients. The tool does not judge when to raise a version number and does not check whether compatibility broke.
Frequently asked questions
A shared cache keys responses on the address by default. When the address is the same but the content depends on a header, the version stored first is handed to a client that asked for another. Naming that header in the Vary response header makes the cache include the header value in its key.
It is a practice that is no longer recommended. Prefixing a non-standard header with X- means that if the header is later standardised, both the prefixed and unprefixed names are in circulation. Starting without the prefix avoids that.
It does not pick a recommended style, judge when to raise a version or check whether compatibility broke. It generates request examples and computes cache and sharing effects.