Introduction

This is the structure of this article,

A - What is Versioning

API is a form of contract between you and your API consumers, it should be stable, consistent, well documented, and properly managed.

Versions allow you to present groups of related APIs to your developers. You can use versions to handle breaking changes in your API safely. Clients can choose to use your new API version when they're ready, while existing clients continue to use an older version.

B - When to Versioning

APIs only need to be up-versioned when a breaking change is made.

Breaking changes include:

C - Why Versioning APIs

For most purposes, each API version can be considered its own independent API. Two different API versions might have different sets of operations and different policies.

With versions you can:

D - How to Versioning APIs

Different API developers have different requirements for versioning. This is the popular ways to make the versioning:

Path-based versioning

When the path versioning scheme is used, the version identifier needs to be included in the URL path for any API requests.

For example

could refer to the same products API but to versions v1 and v2 respectively.

The format of an API request URL when using path-based versioning is:

Header-based versioning

When the header versioning scheme is used, the version identifier needs to be included in an HTTP request header for any API requests. You can specify the name of the HTTP request header.

For example, you might create a custom header named Api-Version, and clients could specify v1 or v2 in the value of this header.

Query string-based versioning

When the query string versioning scheme is used, the version identifier needs to be included in a query string parameter for any API requests. You can specify the name of the query string parameter.

The format of an API request URL when using query string-based versioning is:

For example,

could refer to the same products API but to versions v1 and v2 respectively.

Reference