0

We have some API which consumes our server (Spring MVC controllers). Current version delivery process to customers is:

  • there is a current version (developing new features), stable for real world clients (fixing production bugs only) and other versions are outdated.
  • so when client see outdated on one of API requests he is forced to update its application (android)

Version is set on controller:

@RequestMapping("/v13")
public class FooController

So requests to different versions:

http://foo.com/v10/foo-method (outdated)

http://foo.com/v14/foo-method (this is stable)

The problem is we are delivering versions too fast and our clients suffer from it.

But average client consumes only 10-15% of our API so there was a proposal to mark every API method (i.e. contoller method) to its own version.

Then client provides some manifest with methods he uses and if there no changes in methods he uses - he is not forced to update his application even he is far behind

Did anybody face this problem? And what the typical solutions on this. Thanks.

fasth
  • 2,232
  • 6
  • 26
  • 37
  • I am really against changing the version every time a small change is made. I would change the version whenever the api is completely changed. The problem you are facing is that you should expose your API in that way so you don't need to make changes to it every month or so, but then again that's a problem that everyone is facing when exposing publicly an API, how to expose it in that way so you will only have to do small changes to it. – Andrei Sfat Apr 06 '15 at 12:58
  • see http://stackoverflow.com/questions/389169/best-practices-for-api-versioning – Andrei Sfat Apr 06 '15 at 12:59

0 Answers0