2017-02-07 10:31 GMT-08:00 Ed Leafe <e...@leafe.com>: > On Feb 6, 2017, at 3:28 PM, Ken'ichi Ohmichi <ken1ohmi...@gmail.com> wrote: >> >>> To summarize, my point is that we shouldn't be worried that this case is >>> going to set a precedent. It would be worrisome if it were going to set >>> a *bad* precedent, but when you look at the details of the situation, I >>> don't think it will. So it looks to me, anyway, that a compromise is in >>> order here. (In case I'm being too obscure, what I mean is: we should >>> agree that it's OK for the Glance team to fix this bug in the code with >>> patch https://review.openstack.org/#/c/420038/.) >> >> I feel this case is very common case when we want to chang success status >> code. >> Because I cannot find the other motivation for changing success status >> code except we are finding bugs like this case. > > Success codes are different than failure codes, because when you fail, you > need to know why. When your request succeeds, that’s pretty much all you need > to know. So the pain involved should be much less. > > But aside from this particular case, there are a lot of differing opinions on > how APIs should be treated, so I wrote up my take on things: > > https://blog.leafe.com/api-longevity/ > >> So if accepting this case, I guess we drop the following guideline >> completely[1] >> >> The following types of changes are generally *not* considered acceptable: >> Changing which response code is returned on success. > > I’ll propose a change to the wording for that, but dropping the guideline > completely would be an overreaction, IMO.
I am not sure what you mean, I feel you are saying it is meaningless to specify particular success status code on each API.. One my stupid idea is it is good to specify HTTP200 only on all APIs on the guideline. It would be easy to make APIs consistent and avoid this kind of bugs. I know many people don't prefer this idea ;) Thanks Ken Ohmichi __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
