Open Stack

2017-02-07 10:31 GMT-08:00 Ed Leafe <ed at leafe.com>:
> On Feb 6, 2017, at 3:28 PM, Ken'ichi Ohmichi <ken1ohmichi at 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