CODEWITHSUNDEEP
springrestmicroservicesaws-api-gatewayapi-versioning
Ajanthan
Ajanthan

Reputation: 308

What is the best way to do microservice REST API versioning?

I'm developing this project using Spring and hosting in AWS EC2 instances. As few new requirements coming up, I have to change my API contracts. But I don't want to break the current clients. So, I'm trying to implement some REST APIs with versioning. So that whenever I update the endpoints the consumer applications won't crash. But I'm confused on how to do the API versioning. I thought of two ways.

  1. Create a next version endpoint in the same server,(in spring using RequestMaping("/v1/api1"),RequestMaping("/v2/api1") something like this.)

  2. Other wise completely run the v2 APIs in new server instance but keep the same API endpoint footprint and use AWS APIGateway as a proxy and configure the versioning there, then route to old server and new server depending on the version number in the request.

But the first approach will lead to lot of code duplication and code management messy I believe. Because we are keeping the same functionality with variations.

In the second approach I have to keep two set of instances for bot versions if me Version increases then It's hard to manage those instances, specially, when I will have around 15 micro-service instances. And it'll not be cost effective also. Because my company is a startup , so I need to consider this fact also.

Is there any best practices regarding API versioning and managing multiple version of endpoints? I'm open for any suggestions and guidelines. If multiple server is the solution also, I'm open to reconsider the cost limitations. I need the best solution for this problem.

Upvotes: 5

Views: 8679

Answers (1)

Anunay
Anunay

Reputation: 1893

First question is why you need a new version? Has your contract change or is there some change in internal logic and if you really need to expose a new version. Next question to ask is how long you need to support the old version and how many versions you intend to have. For a mature api and you may make use of approach 2, with smaller footprint if possible. For others you would be in better situation to expose v2 via same service and work around it. Code replication is a factor but depends on what you changing. If its all about change in contract you can try to have same biz logic and make it to work with both new and old contracts.

Here are some links that you may find useful

https://www.mnot.net/blog/2012/12/04/api-evolution

Best practices for API versioning?

Upvotes: 3

Related Questions