Just commited to the PR, FAB_API_SWAGGER_UI = True will attach a BaseView with SwaggerUI so it's easy to visualize
On 2019/04/08 09:03:03, danielvazgas...@gmail.com <danielvazgas...@gmail.com> wrote: > > Ok, so now ModelRestApi generates automatic OpenAPI specs from the CRUD > endpoint, and made > the spec accessible on /api/<version>/_openapi. This endpoint is protected, > but will allow browser session cookies also (besides JWT). > > BaseApi generates spec from YAML method docs. And offers 400-500 already > bundled spec responses for easy referencing ($ref: ) and Rison jsonschema > integration and self registering on /components/parameters > > I'm not bundling a swagger-ui also. Maybe this could be useful for dev. > > > On 2019/04/04 14:28:20, Ash Berlin-Taylor <a...@apache.org> wrote: > > https://github.com/zalando/connexion was the other module we had started > > looking at in Airflow to get OpenAPI for our API. > > > > I think exposing the OpenAPI spec on an endpoint would be good too. The > > spec should be "global" (at least tied to an API version) as all the > > tooling would expect a single endpoint/file to query to build client libs - > > so `/api/v1/_openapi` for instance, and that would contain info about all > > the endpoints in the v1 API. I don't understand your point about RBAC - > > accessing the spec won't perform any actions so there aren't any permission > > concerns are there? > > > > -ash > > > > > On 4 Apr 2019, at 13:44, danielvazgas...@gmail.com wrote: > > > > > > > > > On ModelResApi class, auto generated endpoints for CRUD rison args could > > > be optional but I would not go that way, some thoughts about this: > > > > > > - ModelRestApi offers complex options for selecting columns, metadata > > > keys, filters, pagination, ordering. These options are naturally a nested > > > data structure, and enabling this kind of structure would force me to > > > invent a specific key/value custom specification. I would say that Rison > > > is a standard way of solving this. > > > - Since Rison dumps and loads to JSON, I'm using JSON schema validation. > > > This increases the CRUD API resilience to malicious or unintentional > > > faulty args. > > > - Rison solves out of the box, type arg conversion. > > > > > > Note: You can use "normal" key/value args when developing your own API, > > > extending from BaseApi. > > > > > > Yes, good idea, OpenAPI spec is a very desirable feature, I was already > > > looking at: https://github.com/marshmallow-code/apispec. It seems very > > > doable, even with dynamic schema generation (I still have to try it). I > > > have some doubts: > > > > > > - Should we expose it on some endpoint, if yes, Should it be exposed > > > resource based /api/v1/<resource>/_openapi. Globally could raise issues > > > regarding RBAC permissions. > > > > > > > > > On 2019/04/04 08:59:16, Ash Berlin-Taylor <a...@apache.org> wrote: > > >> Some quick thoughts: > > >> > > >> Rison: Is it optional? Can we (please?) still use query params too? > > >> Hand-crafting/what the parameters look like in the URL is a total-non > > >> issue for me. > > >> > > >> On that front it would be nice if `kwargs['rison']` was more general - > > >> to cope with Rison or traditional query args in the same view based so > > >> something like `kwargs['get']`? > > >> > > >> For example I instead of > > >> http://localhost:8080/api/v1/contact/1?q=(columns:!(name,address))' I > > >> would prefer http://localhost:8080/api/v1/contact/1?columns=name,address > > >> (or ?columns=name&columns=address) > > >> > > >> And yes, having the API be self "documenting"/specifying with OpenAPI > > >> please! This standard lets client libs be auto-generated based on the > > >> schema. > > >> > > >> -ash > > >> > > >> > > >>> On 1 Apr 2019, at 18:49, danielvazgas...@gmail.com wrote: > > >>> > > >>> > > >>> > > >>> On 2019/04/01 17:14:28, Maxime Beauchemin <maximebeauche...@gmail.com> > > >>> wrote: > > >>>> Hey! > > >>>> > > >>>> I wanted to point out that there's awesome work taking place in FAB > > >>>> around > > >>>> a new REST API provided by the framework, and ways to extend it. > > >>>> > > >>>> Daniel Gaspar (cced) is working on this currently, and looking for > > >>>> input on > > >>>> design / implementation. > > >>>> > > >>>> Check it out and chime in on the PR > > >>>> https://github.com/dpgaspar/Flask-AppBuilder/pull/929 > > >>>> > > >>>> I wanted to point out that a good place to start is by reading the > > >>>> `rest_api.rst` file in the PR (github collapses it in the PR interface > > >>>> as > > >>>> it's large, and want to make sure people don't overlook that file) > > >>>> https://github.com/dpgaspar/Flask-AppBuilder/pull/929/files#diff-f0aaa98b108e6453b3a8b2526956b8beR1 > > >>>> > > >>>> Some key elements: > > >>>> * better and more flexible auth, using JWTs > > >>>> * Type awareness > > >>>> * a much better auto REST CRUD, with the ModelRestApi base class > > >>>> * a new way to define REST endpoints and a cohesive API, versioned as > > >>>> in > > >>>> `/api/v1` > > >>>> * Rison integration > > >>>> * i18n > > >>>> > > >>>> This should probably be the foundation to Airflow's REST API as it > > >>>> grows > > >>>> and this is a unique moment to influence the design of FAB's REST API. > > >>>> > > >>>> Max > > >>>> > > >>> Hi, > > >>> > > >>> Feel free to leave comments on the PR or this thread. > > >>> Once more you're input would be highly appreciated. > > >>> > > >>> Docs are available on: > > >>> https://flask-appbuilder.readthedocs.io/en/fab2/rest_api.html > > >>> (I'll be updating readthedocs for this branch) > > >>> > > >>> Some design goals: > > >>> - Security > > >>> - Enable the possibility to develop dynamic CRUD react components on > > >>> top of the ModelRestApi class. > > >>> - Flexibility > > >>> - Coherent API > > >>> > > >>> Thank you! > > >>> Daniel Gaspar > > >>> > > >> > > >> > > > > >
