Versioning REST Web Services

Backwards compatible changes can be quite dangerous... If you are exposing new behaviour you need to consider that it's actually a new version.

Either way, if you're exposing Web Services (REST or otherwise), a versioning strategy is a must to consider - even synchronising a change over a handful of consumers is difficult, let alone if you get hundreds or thousands. This type of environment is almost impossible to maintain without a versioning strategy.

Aside from the mechanics of versions you need to think about the bigger picture - you have a resource with a lifecycle now - so - how do I tell consumers about the versions that are available? how do I deprecate and decommission versions, and how do I tell the stakeholders in this? how do I test multiple versions? are there any coexistance issues I need to be aware of? etc... etc...

I just saw hardline REST create some problems and solve none.

i don't see the advantage vs. adding a version header.