<div dir="ltr"><div dir="ltr"><div dir="ltr">Hi Dmitry,<div> </div><div>Thanks your reply. Absolutely you are a sdk expert.</div><div><br><div dir="ltr">> This is a good first step, but if I get it right it does not specify which <br>> response corresponds to which request.  <br><br>You got it. I think it depends on how to use the API schemas.</div><div>We could define some rules to make sure which response corresponds to which request.</div><div>For example, by order. Maybe you can give some other suggestions.  </div><div dir="ltr">Also, this is not fresh concept, we can find the choice definition in xsd [1].</div><div dir="ltr">By the way, firstly we can sort out OpenStack API schemas ,</div><div dir="ltr">and handle these schemas to the developers and the users,</div><div>and let them to choose how to use it.</div><div><br></div><div dir="ltr">[1] <a href="https://www.w3schools.com/xml/el_choice.asp">https://www.w3schools.com/xml/el_choice.asp</a></div><div dir="ltr"><br></div><div dir="ltr">Best Regards,</div><div dir="ltr">Edison Xiang<br><br><div class="gmail_quote"><div dir="ltr">On Tue, Sep 4, 2018 at 7:01 PM Dmitry Tantsur <<a href="mailto:dtantsur@redhat.com" target="_blank">dtantsur@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi,<br>
<br>
On 08/29/2018 08:36 AM, Edison Xiang wrote:<br>
> Hi team,<br>
> <br>
> As we know, Open API 3.0 was released on July, 2017, it is about one year ago.<br>
> Open API 3.0 support some new features like anyof, oneof and allof than Open API <br>
> 2.0(Swagger 2.0).<br>
> Now OpenStack projects do not support Open API.<br>
> Also I found some old emails in the Mail List about supporting Open API 2.0 in <br>
> OpenStack.<br>
> <br>
> Some limitations are mentioned in the Mail List for OpenStack API:<br>
> 1. The POST */action APIs.<br>
>      These APIs are exist in lots of projects like nova, cinder.<br>
>      These APIs have the same URI but the responses will be different when the <br>
> request is different.<br>
> 2. Micro versions.<br>
>      These are controller via headers, which are sometimes used to describe <br>
> behavioral changes in an API, not just request/response schema changes.<br>
> <br>
> About the first limitation, we can find the solution in the Open API 3.0.<br>
> The example [2] shows that we can define different request/response in the same <br>
> URI by anyof feature in Open API 3.0.<br>
<br>
This is a good first step, but if I get it right it does not specify which <br>
response corresponds to which request.<br>
<br>
> <br>
> About the micro versions problem, I think it is not a limitation related a <br>
> special API Standard.<br>
> We can list all micro versions API schema files in one directory like nova/V2,<br>
<br>
I don't think this approach will scale if you plan to generate anything based on <br>
these schemes. If you generate client code from separate schema files, you'll <br>
essentially end up with dozens of major versions.<br>
<br>
> or we can list the schema changes between micro versions as tempest project did [3].<br>
<br>
++<br>
<br>
> <br>
> Based on Open API 3.0, it can bring lots of benefits for OpenStack Community and <br>
> does not impact the current features the Community has.<br>
> For example, we can automatically generate API documents, different language <br>
> Clients(SDK) maybe for different micro versions,<br>
<br>
 From my experience with writing an SDK, I don't believe generating a complete <br>
SDK from API schemes is useful. Maybe generating low-level protocol code to base <br>
an SDK on, but even that may be easier to do by hand.<br>
<br>
Dmitry<br>
<br>
> and generate cloud tool adapters for OpenStack, like ansible module, terraform <br>
> providers and so on.<br>
> Also we can make an API UI to provide an online and visible API search, API <br>
> Calling for every OpenStack API.<br>
> 3rd party developers can also do some self-defined development.<br>
> <br>
> [1] <a href="https://github.com/OAI/OpenAPI-Specification" rel="noreferrer" target="_blank">https://github.com/OAI/OpenAPI-Specification</a><br>
> [2] <br>
> <a href="https://github.com/edisonxiang/OpenAPI-Specification/blob/master/examples/v3.0/petstore.yaml#L94-L109" rel="noreferrer" target="_blank">https://github.com/edisonxiang/OpenAPI-Specification/blob/master/examples/v3.0/petstore.yaml#L94-L109</a><br>
> [3] <br>
> <a href="https://github.com/openstack/tempest/tree/master/tempest/lib/api_schema/response/compute" rel="noreferrer" target="_blank">https://github.com/openstack/tempest/tree/master/tempest/lib/api_schema/response/compute</a><br>
> <br>
> Best Regards,<br>
> Edison Xiang<br>
> <br>
> <br>
> <br>
> __________________________________________________________________________<br>
> OpenStack Development Mailing List (not for usage questions)<br>
> Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
> <br>
<br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</blockquote></div></div></div></div></div></div>