I previously pointed to the announcement of the shutdown of a version of the Google Adwords API, and commented that this really isn’t the way to go about versioning your Web 2.0 APIs.

I’ve been digging into Google Maps recently, and noticed that they’re making the same mistake;

The v=2 part of the URL http://maps.google.com/maps?file=api&v=2 refers to “Version 2 ” of the API. When we do a significant update to the API in the future, we will change the version number and post a notice on Google Code and the Maps API discussion group.

After a new version is released, we will try to run the old and new versions concurrently for about a month. After a month, the old version will be turned off, and code that uses the old version will no longer work.

Obviously we’re still pretty early into the whole “mashup” thing, but not too early that we shouldn’t be thinking about best practices IMO. And best practice #1? Don’t do what Google’s doing here, which is asking all their users – mashup developers who have committed themselves to this service – to absorb the cost of their inability to develop an extensible API.

I think a good rule of thumb for service providers is to assume that you’ve got a million mashups using your service, and therefore that the cost of incompatible changes is prohibitive for the mashup developers. Any other approach is sure to drive those developers to other service providers who do a better job evolving their APIs; bad juju if your business depends on attracting eye-balls.

So what constitutes a “better job”? I suggest it has something to do with declarative Javascript, but my argument needs some work so I’ll save that for another post.

Trackback

only 1 comment until now

  1. […] Following up on my finger-wag at Google for not properly supporting mashup developers by messing up versioning, I have to now send them full props for one thing they’re doing very, very, right. […]

Add your comment now