Open Stack

On 2014年02月26日 18:40, Thierry Carrez wrote:
> Kenichi Oomichi wrote:
>>> From: Christopher Yeoh [mailto:cbkyeoh at gmail.com]
>>> So the problem here is what we consider a "bug" becomes a feature from
>>> a user of the API point of view. Eg they really shouldn't be passing
>>> some data in a request, but its ignored and doesn't cause any issues
>>> and the request ends up doing what they expect.
>> In addition, current v2 API behavior is not consistent when receiving
>> unexpected API parameters. Most v2 APIs ignore unexpected API parameters,
>> but some v2 APIs return a BadRequest response. For example, "update host"
>> API does it in this case by https://github.com/openstack/nova/blob/master/nova/api/openstack/compute/contrib/hosts.py#L185
>>
>> Through v3 API development, we are making all v3 APIs return a BadRequest
>> in this case. I think we cannot apply this kind of strict validation to
>> running v2 API.
> We may need to differentiate between breaking the API and breaking
> corner-case behavior. 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.
>
> So there may be a middle ground between "sticking with dirty V2 forever"
> and "Go to V3 and accept a long V2 deprecation":

Let us find the middle ground, how about this:

v3: This is the total new api. it's with CamelCase fixing, stronger 
input vaildation, api policy checks, and task api.

v2.1: This is based on v3, we transform the v2 request into v3 
request(then they are share same codebase). This api is without 
CamelCase fixing. And it get new thing from v3: stronger input 
vaildation, api policy checks, task api. We are keeping this api for 
long time. V2.1 didn't break the api. This api only affect those that 
were not following v2 api correctly.

v2: just go away after a shorter deprecation period.

So v3 and v2.1 based on same code, this is reduce the cost of 
maintenance. v2 is keeping for short time, give people a chance to move 
to v2.1 or v3.
And v2.1 didn't break the api, and it's more easy for maintenance.

> 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.
>