Versioning

Changes in an API are inevitable as your understanding and experience with a system evolve. To effectively manage the impact of these changes, we have implemented URI versioning.

URI Versioning

One approach to version a REST API is by incorporating the version number within the URI path. When the version is introduced in the URI space, the representations of resources are treated as immutable. Therefore, when modifications are necessary, a new URI space must be created.

For instance, consider an API that provides the following resources: customers and items:
http://api.techrar.com/api/v1/customers http://api.techrar.com/inventory/v1/items
If a breaking change occurs in the users API, we would introduce a second version:
http://api.techrar.com/api/v2/customers http://api.techrar.com/inventory/v2/items

When to Add a New Version?

APIs should only be versioned up when a breaking change occurs. Breaking changes may include:
Alterations in the format of the response data for one or more calls
Changes in the request or response type (e.g., changing an integer to a float)
Removal of any component of the API.

Changelog

The changelog details every available version.

URI Versioning#

When to Add a New Version?#

Changelog#

URI Versioning

When to Add a New Version?

Changelog