drewsonne edited a comment on issue #4640: [WIP] Feature/flask restful URL: https://github.com/apache/airflow/pull/4640#issuecomment-461735905 @feng-tao I would argue that is not a positive structure to take for the API, as it is: a) not an API describing the airflow application and its models, but an API describing flask models, b) relies on filters in query params for identifying unique resources, rather than providing them with a URI. As a small point, it _looks like_ it would require building the ModelView models, so in tersm of "free", there's still sizeable work to be done and the potential for double sets of models (the existing airflow.models and the new ModelViews), unless mixins were used. If you're an external app developer, you need to work with two sets of model descriptions: the models you actually want to interact with (Dag, Connection, TaskInstance, etc); and the flask-appbuilder models (`/read`, `/delete`, `/column/add/...`, etc) Without being religious about it, it takes away the expected "Restfulness" of the API as well. You don't have resources at expected URI's to interact with. Instead you use parameters to define exactly which flask models you wish to query against, as opposed to which airflow resources. As an example this is the difference between ``` GET /experimental/api/dags/my_custom_dag HTTP/1.1 ``` and ``` GET /experimental/api/dags?_flt_0_field_string_dag_name=my_custom_dag HTTP/1.1 ``` If I understand the flask-appbuilder REST functionality, it requires the use of the SQLAInterface object to build an abstracted version databases tables. I think it's a good idea to build these in general (not neccesariy for this feature). I think what you get for free from the flask-appbuilder after building the models this is better served by using a common industry convention (OpenAPI3), rather than the flask implementation, which in my opinon is quite tightly coupled to flask itself (eg, filters like `_flt_...`). Using OpenAPI3 means we leave external parties to generate clients to interact with airflow in any language which the [autogenerator](https://github.com/OpenAPITools/openapi-generator) supports. This opens up airflow to being intereacted with by other tools without having to undertake the tedious task of writing each API call into the client automatically. _note_: Although we could maintain a swagger definition file in parallel, I think it would eventually fall by the way side and drift from the actual implementation.
---------------------------------------------------------------- This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: [email protected] With regards, Apache Git Services
