Open Stack

> >> Do you reckon this change warrants a full major version bump?
> >
> > Generally speaking non-backwards-compatible changes do require a
> > version
> > bump, yes. I know it seems like a trivial change, but it would
> > break all
> > clients expecting a 200 where a 201/202 would now be returned.
> 
> Agreed, I expect a number of clients are checking for 200, and not a
> generic 2xx status code. So, while I am all in favor of this change,
> I think it requires a version bump.

Thanks Jay & Sean for the responses,

Normally I'd agree with you that we need to very reticent about breaking
backward compatibility, however in this case I suspect we may be talking
about bug compatibility.

The way the code is structured (defaulting to a 200 response code, as
opposed to setting this explicitly) and the fact that some other native
APIs return 202 on resource creation, led to me to believe that the
current behavior may be the result of an over-sight as opposed to a
deliberate choice.

Would the requirement to bump the version still hold if the 200 status 
was returned in error, or would that still be protected as part of the
"de facto" API?

Cheers,
Eoghan