Dealing with API drift is an interesting problem and a constant challenge on the mobile systems I’ve worked on. Following Postel’s Law our APIs should be reasonably accepting of incoming data and what they produce. A line must eventually be drawn somewhere though and there isn’t always a strong business case for supporting older versions. Sometimes this is motivated purely by user count while others it’s a shfit in serivce’s domain.

We’re begining to close out a major shift in our core domain model. For a young company this isn’t unusual however this is my first go around in a piviot. We’ve scoped API calls in Django under an increment version name, for example api/v2 has now become api/v3 for the path components. With this piviot we are forcing all clients to upgrade to use the new system. This leaves at least one path component which needs to remain under the v2 namespace: compatability. We’ve settled on aliasing the path at the current time to the new location of the resource interpreter but I’m left wondering if there is a better way.

In a world where I could build any system I please I suppose I would have an external service who coordinates availability as well as compatability. This would also allow for rolling updates without effecting older versions of the API. I’m sure this will come up and this is definitely not tempered through production support yet. Hopefully I’ll get a chance to distill this vaporware into a reall system in the near future.