Great work Kamil, I can't wait till we have a fully featured API in Airflow!
So AIP-13 has been voted on and "accepted". Do you have a proposal for what we should do with that AIP that we've already voted upon? In the permissions section you talk about creating, for example "can_edit_variable" -- but on which view? Permissions in FAB are a on a specific view -- see https://github.com/dpgaspar/Flask-AppBuilder/blob/120bc3ca38c4559a0099fe3b1a1badb319b6546e/flask_appbuilder/security/sqla/models.py#L71-L78 "There are not many FAB REST API experts" -- there aren't that many connexion experts either - has anyone involved with the project used connexion before?. It's a wildly inaccurate metric, but https://hugovk.github.io/top-pypi-packages/ lists FAB in position 980 and connexion in 1146, so they are both about as popular as each other. On Feb 26 2020, at 4:40 pm, Kamil Breguła <kamil.breg...@polidea.com> wrote: > Hello, > > I just created "AIP-32 - Airflow REST API" proposal and would love > community feedback and comments. > https://cwiki.apache.org/confluence/display/AIRFLOW/AIP-32%3A+Airflow+REST+API > I would love to know what is your expectation from the API. > > We currently have one experimental API, but despite its existence for > 2 years, it has not reached a stable level. There are many critical > aspects to this implementation including no defined schema, very > narrow range of functions, unsafe default configuration, no HATEOAS, > and many others. > > In the past, Drewstone began work on REST API based on OpenAPI. It's > described by AIP-13: OpenAPI 3 based API definition. However, it was > not completed due to the lack of interest from the author and the > Kerberos configuration problem (It was at a time when Breeze was still > developing, so configuring all dependencies, including Kerberos, was a > problem). It had a narrow range of features that are expected by users > e.g. access to XCOM data and management for connection is missing, > > The Polidea and Google teams together with the community want to make > another attempt based on our and community experience. Airflow > deserves new stable solutions. > > Any comments and feedback/discussion in the AIP-32 document are welcome! > Best regards, > Kamil Breguła >
