Web Services Versioning

When designing a traditional ▲HTTP-based web service, one can make a safe assumption that, as long as the remote web server is available, it will provide the given service. Even if the service is enhanced or updated over time, web designers take stock in the fact that version 1 of the web interface is still there. As a web service is enhanced over time, the service provider might offer versions 2, 3, 4, or 5 of a given service. For this reason, many traditional web services expose those interfaces through URIs of the form /v1/sample_service or /v3/sample_service. A client of that service that was written for version 1 will still be able to access the version 1 service.

However, the environment is quite different for communication systems that are not bound to a given, known web server. For example, suppose you have a mobile phone with version 4 of a particular web-based client on your mobile handset. Suppose you want to establish communication with a friend who has a similar mobile handset, but is running version 3 of the same software. If your client attempts to access /v4/sample_service, it will fail since your friend does not have this version of the service. Your client could try each known version in turn, but this creates unacceptable complexity and delay for any real-time multimedia system.

The right solution is to design communication protocols between such independent communication systems in such a way that messages are both forward and backward compatible. By that, we mean that newer systems can properly exchanges messages with older systems and, likewise, older systems are properly able to exchange messages with newer systems. Most importantly, such message exchanges must result in useful and meaningful communication such that the user gets what he expects.

Refer to the XML protocol versioning page for discussion on how to design properly versioned ▲XML-based communication protocols.