To view the API spec
<https://github.com/PolideaInternal/airflow/blob/1e3e444d03c2e08d8fcee274d9e745a3d3ddeca8/openapi.yaml>
in an easier to consume form I used https://editor.swagger.io/ and imported
from the (raw) github URL
Some comments on the proposed OpenAPI spec;
connection id's are not unique, so get/delete might operate on multiple
entries. (This has caused some confusion in the past, but is probably a
separate issue to adding a REST API)
dag_id is listed as "integer" type. it should be string. Same applies to most
other id types it appears.
PATCH dag: fileloc shouldn't be writable (it's a security risk), is_active and
is_subdag are an internal field and shouldn't be writable either.
PATCH dag: - Did you think about/rule out having separate /dag/{dag_id}/pause
and unpause methods?
I don't think taskReschedule should be exposed directly at all - it's an
internal detail for sensors in a specific state.
PATCH variables - update_mask parameter: The way I've seen other APIs do this
is PATCH vs PUT requests. PATCH should only update the specified fields, PUT is
"here is the entire representation, make it look like this"
PATCH variables - is_encrypted is exposed. It shouldn't be. It is not
user-setable (it has is not writable in the UI anymore)
GET xComValues: This endpoint support reading resources across multiple Task
Instancce by specify a "-" as a !! - as a separator is not going to work. That
is a valid character in task ids.
xComValues -- I feel the "values" is out of place/not needed.
-ash
(The thought of maintaining that swagger/openapi spec file is honestly a bit
daunting and making me lean more towards adding spec validation to FAB than
using connexion - specifically because it's a: huge and b: lives separately to
the code/endpoints)
On Feb 28 2020, at 3:15 pm, Ash Berlin-Taylor <a...@apache.org> wrote:
> 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
> >
>
