Open Stack

> We may need to differentiate between breaking the API and breaking
> corner-case behavior.

Totally agreed.

> In one case you force everyone in the ecosystem to
> adapt (the libraries, the end user code). In the other you only
> (potentially) affect those that were not following the API correctly.

The problem is that the API spec is too loose right now, which is
definitely a problem. However, I think I'd much rather tighten things
down and deal with the potential fallout of someone's client breaking
and saying "oh, I thought 'red' was a valid uuid" than whole rewrites.

> We could make a V3 that doesn't break the API, only breaks behavior in
> error cases due to its stronger input validation. A V3 that shouldn't
> break code that was following the API, nor require heavy library
> changes. It's still a major API bump because behavior may change and
> some end users will be screwed in the process, but damage is more
> limited, so V2 could go away after a shorter deprecation period.

What's the difference between saying "/v2 will return a 404 after K" and
saying "If your client doesn't declare support for revision 2 of these
calls" we'll return a 405, 406, 410, etc? Actually, 412 seems to be
exactly this case.

--Dan