Which versioning approach uses a version in the API path, such as /v1/?

• A. Header versioning
• B. Path versioning
• C. Content negotiation
• D. Deprecation window management

Answer: (B)

Placing the version in the API path means the version becomes part of the endpoint itself, like /v1/... This makes each version its own namespace, so a request to /v1/ users goes to the v1 behavior and data, while /v2/ users follows the newer version. That clarity helps routing and caching, because every version is a separate resource and can be evolved independently without risking cross-version mix-ups. It also makes it easy for clients to target a specific version and for servers to deprecate old versions by simply retiring that path, while keeping newer paths available.

Using a version in a header hides versioning from the URL, which can complicate caching and visibility for intermediaries. Content negotiation relies on headers or media types to decide representation, which is more about data format and can blur version boundaries. A deprecation window is a lifecycle policy rather than a versioning mechanism by itself, so it doesn’t specify how versions are exposed at all.