Best practices for API versioning

0 votes

Are there any known how-tos or best practices for web service REST API versioning?

I have noticed that AWS does versioning by the URL of the endpoint. Is this the only way or are there other ways to accomplish the same goal? If there are multiple ways, what are the merits of each way?

Aug 2, 2018 in AWS by Priyaj
• 58,020 points
2,406 views

1 answer to this question.

0 votes

This is a good and a tricky question. The topic of URI design is at the same time the most prominent part of a REST API and, therefore, a potentially long-term commitment towards the users of that API.

Since evolution of an application and, to a lesser extent, its API is a fact of life and that it's even similar to the evolution of a seemingly complex product like a programming language, the URI design should have less natural constraints and it should be preserved over time. The longer the application's and API's lifespan, the greater the commitment to the users of the application and API.

On the other hand, another fact of life is that it is hard to foresee all the resources and their aspects that would be consumed through the API. Luckily, it is not necessary to design the entire API which will be used until Apocalypse. It is sufficient to correctly define all the resource end-points and the addressing scheme of every resource and resource instance.

Over time you may need to add new resources and new attributes to each particular resource, but the method that API users follow to access a particular resources should not change once a resource addressing scheme becomes public and therefore final.

This method applies to HTTP verb semantics (e.g. PUT should always update/replace) and HTTP status codes that are supported in earlier API versions (they should continue to work so that API clients that have worked without human intervention should be able to continue to work like that).

Furthermore, since embedding of API version into the URI would disrupt the concept of hypermedia as the engine of application state (stated in Roy T. Fieldings PhD dissertation) by having a resource address/URI that would change over time, I would conclude that API versions should not be kept in resource URIs for a long time meaning that resource URIs that API users can depend on should be permalinks.

Sure, it is possible to embed API version in base URI but only for reasonable and restricted uses like debugging a API client that works with the the new API version. Such versioned APIs should be time-limited and available to limited groups of API users (like during closed betas) only. Otherwise, you commit yourself where you shouldn't.

A couple of thoughts regarding maintenance of API versions that have expiration date on them. All programming platforms/languages commonly used to implement web services (Java, .NET, PHP, Perl, Rails, etc.) allow easy binding of web service end-point(s) to a base URI. This way it's easy to gather and keep a collection of files/classes/methods separate across different API versions.

From the API users POV, it's also easier to work with and bind to a particular API version when it's this obvious but only for limited time, i.e. during development.

From the API maintainer's POV, it's easier to maintain different API versions in parallel by using source control systems that predominantly work on files as the smallest unit of (source code) versioning.

However, with API versions clearly visible in URI there's a caveat: one might also object this approach since API history becomes visible/aparent in the URI design and therefore is prone to changes over time which goes against the guidelines of REST. I agree!

The way to go around this reasonable objection, is to implement the latest API version under versionless API base URI. In this case, API client developers can choose to either:

  • develop against the latest one (committing themselves to maintain the application protecting it from eventual API changes that might break their badly designed API client).

  • bind to a specific version of the API (which becomes apparent) but only for a limited time

For example, if API v3.0 is the latest API version, the following two should be aliases (i.e. behave identically to all API requests):

http://example/api/customers/1234
http://example/api/v3.0/customers/1234
http://example/api/v3/customers/1234
 

In addition, API clients that still try to point to the old API should be informed to use the latest previous API version, if the API version they're using is obsolete or not supported anymore. So accessing any of the obsolete URIs like these:

http://example/api/v2.2/customers/1234
http://example/api/v2.0/customers/1234
http://example/api/v2/customers/1234
http://example/api/v1.1/customers/1234
http://example/api/v1/customers/1234
 

should return any of the 30x HTTP status codes that indicate redirection that are used in conjunction with Location HTTP header that redirects to the appropriate version of resource URI which remain to be this one:

http://example/api/customers/1234

answered Aug 2, 2018 by bug_seeker
• 15,510 points

Related Questions In AWS

0 votes
1 answer

What are the best practices for security in Lambda?

For security, there are some of the ...READ MORE

answered Jan 11, 2019 in AWS by Diksha
714 views
0 votes
1 answer
0 votes
1 answer

AWS Cloudtrail API for Go SDK showing an error mesage.

You  must add S3 Policy in your ...READ MORE

answered Jun 27, 2018 in AWS by Flying geek
• 3,280 points
1,318 views
0 votes
1 answer
0 votes
1 answer
0 votes
1 answer

How to provide tags for the stack in CloudFormation Template?

In the template anatomy, you cant set ...READ MORE

answered Aug 13, 2018 in AWS by bug_seeker
• 15,510 points
19,613 views
0 votes
1 answer

EC2 API throttling limits

Amazon EC2 has meanwhile documented their general Query API ...READ MORE

answered Aug 13, 2018 in AWS by bug_seeker
• 15,510 points
1,412 views
webinar REGISTER FOR FREE WEBINAR X
REGISTER NOW
webinar_success Thank you for registering Join Edureka Meetup community for 100+ Free Webinars each month JOIN MEETUP GROUP