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 <[email protected]> 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, [email protected] wrote: > > > > > > > > On 2019/04/01 17:14:28, Maxime Beauchemin <[email protected]> > > 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 > > > >
