Airflow API

Overview To facilitate management, Apache Airflow supports a range of REST API endpoints across its objects. This section provides an overview of the API design, methods, and supported use cases. Most of the endpoints accept JSON as input and return JSON responses. This means that you must usually add the following headers to your request: Content-type: application/json Accept: application/json Resources The term resource refers to a single type of object in the Airflow metadata. An API is broken up by its endpoint's corresponding resource. The name of a resource is typically plural and expressed in camelCase. Example: dagRuns . Resource names are used as part of endpoint URLs, as well as in API parameters and responses. CRUD Operations The platform supports C reate, R ead, U pdate, and D elete operations on most resources. You can review the standards for these operations and their standard parameters below. Some endpoints have special behavior as exceptions. Create To create a resource, you typically submit an HTTP POST request with the resource's required metadata in the request body. The response returns a 201 Created response code upon success with the resource's metadata, including its internal id , in the response body. Read The HTTP GET request can be used to read a resource or to list a number of resources. A resource's id can be submitted in the request parameters to read a specific resource. The response usually returns a 200 OK response code upon success, with the resource's metadata in the response body. If a GET request does not include a specific resource id , it is treated as a list request. The response usually returns a 200 OK response code upon success, with an object containing a list of resources' metadata in the response body. When reading resources, some common query parameters are usually available. e.g.: v1/connections?limit=25&offset=25 Query Parameter Type Description --------------- ---- ----------- limit integer Maximum number of objects to fetch. Usually 25 by default offset integer Offset after which to start returning objects. For use with limit query parameter. Update Updating a resource requires the resource id , and is typically done using an HTTP PATCH request, with the fields to modify in the request body. The response usually returns a 200 OK response code upon success, with information about the modified resource in the response body. Delete Deleting a resource requires the resource id and is typically executing via an HTTP DELETE request. The response usually returns a 204 No Content response code upon success. Conventions - Resource names are plural and expressed in camelCase. - Names are consistent between URL parameter name and field name. - Field names are in snake case. json { "name": "string", "slots": 0, "occupied slots": 0, "used slots": 0, "queued slots": 0, "open slots": 0 } Update Mask Update mask is available as a query parameter in patch endpoints. It is used to notify the API which fields you want to update. Using update mask makes it easier to update objects by helping the server know which fields to update in an object instead of updating all fields. The update request ignores any fields that aren't specified in the field mask, leaving them with their current values. Example: resource = request.get('/resource/my-id').json() resource['my field'] = 'new-value' request.patch('/resource/my-id?update mask=my field', data=json.dumps(resource)) Versioning and Endpoint Lifecycle - API versioning is not synchronized to specific releases of the Apache Airflow. - APIs are designed to be backward compatible. - Any changes to the API will first go through a deprecation phase. Trying the API You can use a third party client, such as [curl](https://curl.haxx.se/), [HTTPie](https://httpie.org/), [Postman](https://www.postman.com/) or [the Insomnia rest client](https://insomnia.rest/) to test the Apache Airflow API. Note that you will need to pass credentials data. For e.g., here is how …