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. -- Ed Leafe __________________________________________________________________________ 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
