3

By pointing my application at

I could keep up with all the version changes released.

Alternate forms to stay within major version might be:

Improve this question
2

2 Answers 2

Reset to default
8

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
  • Once required request parameter no longer required?
  • people rely on error conditions, often unintentionally*
  • Larger default sizes?
  • fixed size buffers will be smashed left and right

The only thing we could maybe safely do is add new methods.

But what's the point of that? You'd have to recompile your code to take advantage of the new methods anyway, might as well kick up the version number while you're in there.

Note that all of these problems become infinitely worse once you consider libraries. Now apps stop working because of some code the developer doesn't know, and may have no control over.

*As an aside, The Old New Thing will make you very paranoid about application compatibility. Consider that a recommendation.

Improve this answer
1
  • 1
    Good points. I hereby withdraw the request.
    – Joel
    May 22, 2010 at 0:08
2

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.

Improve this answer
1
  • 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
    May 21, 2010 at 16:50

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .