Open Stack

Hi Dmitry,

Thanks your reply. Absolutely you are a sdk expert.

> This is a good first step, but if I get it right it does not specify
which
> response corresponds to which request.

You got it. I think it depends on how to use the API schemas.
We could define some rules to make sure which response corresponds to which
request.
For example, by order. Maybe you can give some other suggestions.
Also, this is not fresh concept, we can find the choice definition in xsd
[1].
By the way, firstly we can sort out OpenStack API schemas ,
and handle these schemas to the developers and the users,
and let them to choose how to use it.

[1] https://www.w3schools.com/xml/el_choice.asp

Best Regards,
Edison Xiang

On Tue, Sep 4, 2018 at 7:01 PM Dmitry Tantsur <dtantsur at redhat.com> wrote:

> Hi,
>
> On 08/29/2018 08:36 AM, Edison Xiang wrote:
> > Hi team,
> >
> > As we know, Open API 3.0 was released on July, 2017, it is about one
> year ago.
> > Open API 3.0 support some new features like anyof, oneof and allof than
> Open API
> > 2.0(Swagger 2.0).
> > Now OpenStack projects do not support Open API.
> > Also I found some old emails in the Mail List about supporting Open API
> 2.0 in
> > OpenStack.
> >
> > Some limitations are mentioned in the Mail List for OpenStack API:
> > 1. The POST */action APIs.
> >      These APIs are exist in lots of projects like nova, cinder.
> >      These APIs have the same URI but the responses will be different
> when the
> > request is different.
> > 2. Micro versions.
> >      These are controller via headers, which are sometimes used to
> describe
> > behavioral changes in an API, not just request/response schema changes.
> >
> > About the first limitation, we can find the solution in the Open API 3.0.
> > The example [2] shows that we can define different request/response in
> the same
> > URI by anyof feature in Open API 3.0.
>
> This is a good first step, but if I get it right it does not specify which
> response corresponds to which request.
>
> >
> > About the micro versions problem, I think it is not a limitation related
> a
> > special API Standard.
> > We can list all micro versions API schema files in one directory like
> nova/V2,
>
> I don't think this approach will scale if you plan to generate anything
> based on
> these schemes. If you generate client code from separate schema files,
> you'll
> essentially end up with dozens of major versions.
>
> > or we can list the schema changes between micro versions as tempest
> project did [3].
>
> ++
>
> >
> > Based on Open API 3.0, it can bring lots of benefits for OpenStack
> Community and
> > does not impact the current features the Community has.
> > For example, we can automatically generate API documents, different
> language
> > Clients(SDK) maybe for different micro versions,
>
>  From my experience with writing an SDK, I don't believe generating a
> complete
> SDK from API schemes is useful. Maybe generating low-level protocol code
> to base
> an SDK on, but even that may be easier to do by hand.
>
> Dmitry
>
> > and generate cloud tool adapters for OpenStack, like ansible module,
> terraform
> > providers and so on.
> > Also we can make an API UI to provide an online and visible API search,
> API
> > Calling for every OpenStack API.
> > 3rd party developers can also do some self-defined development.
> >
> > [1] https://github.com/OAI/OpenAPI-Specification
> > [2]
> >
> https://github.com/edisonxiang/OpenAPI-Specification/blob/master/examples/v3.0/petstore.yaml#L94-L109
> > [3]
> >
> https://github.com/openstack/tempest/tree/master/tempest/lib/api_schema/response/compute
> >
> > Best Regards,
> > Edison Xiang
> >
> >
> >
> >
> __________________________________________________________________________
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20180906/e121d0cb/attachment.html>