2 Answers
2

I guarantee that if we did this, a large chunk of the developed apps would rely on /latest and break horrendously every time we rev'ed the API. The end user experience would be bad, developers would be frustrated (as their code literally just stopped working one afternoon), and we'd have to deal with a bunch of erroneous bug reports ("/some/method stopped blah blah" - "no, its been updated to instead blah blah").

Even limiting 'latest' behavior to within a major version is a bad idea. Consider what could be allowed to change while still only being a 'minor' revision.

New fields?

somebody is going to have sufficiently brittle JSON parsing code to break

New possible values in existing fields?

using Enum.Parse (or equivalent) is going to be a very common way of dealing with *_type fields, and that would break

Once conditionally returned fields always returned?

somebody is going to have an over-specified object tree and crash when they see something "impossible" in the previous version

If you are thinking about creating a full fledged application that could be open to users, I highly suggest against using a latest version API call. This is because even though you want to keep up with the latest version, it would be horrible for your application to break, and your users to have to wait until you dealt with the changes to the API to be able to use your service again.

The only place I can see this being viable is possibly a development area, but do you really want to go to sleep, and then wake up the next morning to a bunch of error messages? I think it would be far better to simply keep up with the changes on the site, and then update the version you use when you are ready.

If you insist on creating a latest version API, I would make sure that users are strongly cautioned when using it.

Depending on complexity of the app, it is quite possible that breaking changes between minor (and even major) versions would be few and far between. Personally I would use a 1.n approach since minor versions should have very limited breaking changes.
–
Joel PotterMay 21 '10 at 16:50