1

I have a REST API (v1) which routes through to a Java springboot component for which I now need to introduce a number of breaking changes to add new and changed functionality (v2).

I understand how I can use a version number in the URL or HTTP headers to signal whether a client is calling for v1 or v2. My question is how I then control the Java code that implements this. Do I keep a single component with effectively a Case statement at the top which says 'if v1 then do this old logic', if v2 then do this new logic', with the new and old logic perhaps separated into separate methods?

Or is there another approach that is typically adopted - e.g. create an entirely new component for v2 which is deployed alongside v1.

1
  • 1
    I can't speak to Java specifically so I won't post an answer, but in C# you can set the controller's route, and could include a version number in that route. E.g. "/people/v1" routes to PeopleV1Controller, "/people/v2" routes to PeopleV2Controller, and so on.
    – Flater
    Nov 9, 2020 at 13:41

1 Answer 1

4

You could manage it in code by creating v1 and v2 packages with the functionality that differs and having some code to decide which version to run from the controller level. It is entirely possible, but it will be hard to keep track of even with a high level of discipline.

What you might consider doing is maintaining long running branches for v1 and v2 in your source code repository (merging appropriate changes back and forth) and switching between them at the infrastructure level. You can set up a proxy in front of them that switches on whether to forward traffic to v1 or v2 based on the URL or header. An API Management Gateway would have this capability and an nginx reverse proxy based on URL would be fairly easy to configure (https://docs.nginx.com/nginx/admin-guide/web-server/reverse-proxy/).

1
  • +1 for switching at infrastructure level. Although this sounds like a duplication of resources (keeping separate services running for v1 and v2) this might in fact offer the least painful transition route. You don't risk breaking the old service because you don't touch it at all (if the client has been written with the ability of using different base URLs) and to complete the transition you only need to shut down the old service, which means you don't risk breaking the new service for that step. Nov 9, 2020 at 14:19

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.