As I mentioned, we just discovered all handlers along with their urls (Tornado pre-processed url regexps so this was bit easier) and all models (we used Django). Based on this we set up a handler that generated Swagger JSON file according to this schema

https://github.com/swagger-api/swagger-spec/blob/master/versions/2.0.md

Swagger UI was told to use the URL of this handler as the feed of the spec and that's basically all. We didn't implement auth since we wanted the docs to be widely visible. We did have Basic Auth though but that was on nginx side which stood in front of the whole API.

P.

On 12/01/2014 08:00 PM, Dmitriy Shulyak wrote:
Swagger is not related to test improvement, but we started to discuss it here so..

@Przemyslaw, how hard it will be to integrate it with nailgun rest api (web.py and handlers hierarchy)?
Also is there any way to use auth with swagger?

On Mon, Dec 1, 2014 at 1:14 PM, Przemyslaw Kaminski <pkamin...@mirantis.com <mailto:pkamin...@mirantis.com>> wrote:


    On 11/28/2014 05:15 PM, Ivan Kliuk wrote:
    Hi, team!

    Let me please present ideas collected during the unit tests
    improvement meeting:
    1) Rename class ``Environment`` to something more descriptive
    2) Remove hardcoded self.clusters[0], e.t.c from ``Environment``.
    Let's use parameters instead
    3) run_tests.sh should invoke alternate syncdb() for cases where
    we don't need to test migration procedure, i.e. create_db_schema()
    4) Consider usage of custom fixture provider. The main
    functionality should combine loading from YAML/JSON source and
    support fixture inheritance
    5) The project needs in a document(policy) which describes:
        - Tests creation technique;
        - Test categorization (integration/unit) and approaches of
    testing different code base
        -
    6) Review the tests and refactor unit tests as described in the
    test policy
    7) Mimic Nailgun module structure in unit tests
    8) Explore Swagger tool <http://swagger.io/>

    Swagger is a great tool, we used it in my previous job. We used
    Tornado, attached some hand-crafted code to RequestHandler class
    so that it inspected all its subclasses (i.e. different endpoint
    with REST methods), generated swagger file and presented the
    Swagger UI (https://github.com/swagger-api/swagger-ui) under some
    /docs/ URL.
    What this gave us is that we could just add YAML specification
    directly to the docstring of the handler method and it would
    automatically appear in the UI. It's worth noting that the UI
    provides an interactive form for sending requests to the API so
    that tinkering with the API is easy [1].

    [1]
    
https://www.dropbox.com/s/y0nuxull9mxm5nm/Swagger%20UI%202014-12-01%2012-13-06.png?dl=0

    P.

-- Sincerely yours,
    Ivan Kliuk


    _______________________________________________
    OpenStack-dev mailing list
    OpenStack-dev@lists.openstack.org  
<mailto:OpenStack-dev@lists.openstack.org>
    http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


    _______________________________________________
    OpenStack-dev mailing list
    OpenStack-dev@lists.openstack.org
    <mailto:OpenStack-dev@lists.openstack.org>
    http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Reply via email to