November 13, 2016 at 12:39PM
What is API Microversioning and Why Should API Providers Consider It? #readingToday

The basic idea behind API microversioning is that even the slightest change to an API would constitute a new microversion number. In the video, the presenters routinely refer to version 2 of an API whose microversions span 2.0 to 2.22. All microversions are kept in production simultaneously, there's one endpoint that services all of them, and the consuming developer specifies which microversion s/he prefers using a field in the HTTP header (what they call a "magic header field"). Additionally, a secondary "versions API" runs sidecar to the primary API -- one that can be interrogated by the developer in order to figure out things like what is the API's current version, what is the range of supported microversions (ie: 2.0 to 2.22), and what other primary versions (ie: 1.0) are still supported. 

Taken together, API versioning and retirement constitute the last of the eight phases of API lifecycle management. They're also considered to be an art unto themselves. Taking that art to another level however could involve some new thinking that involves the idea of "microversioning."