Bindings API reference

Detailed documentation on the bindings API

Dapr provides bi-directional binding capabilities for applications and a consistent approach to interacting with different cloud/on-premise services or systems. Developers can invoke output bindings using the Dapr API, and have the Dapr runtime trigger an application with input bindings.

Examples for bindings include Kafka, Rabbit MQ, Azure Event Hubs, AWS SQS, GCP Storage to name a few.

Bindings Structure

A Dapr Binding yaml file has the following structure:

  1. apiVersion: dapr.io/v1alpha1
  2. kind: Component
  3. metadata:
  4. name: <NAME>
  5. namespace: <NAMESPACE>
  6. spec:
  7. type: bindings.<TYPE>
  8. metadata:
  9. - name: <NAME>
  10. value: <VALUE>

The metadata.name is the name of the binding.

If running self hosted locally, place this file in your components folder next to your state store and message queue yml configurations.

If running on kubernetes apply the component to your cluster.

Note: In production never place passwords or secrets within Dapr component files. For information on securely storing and retrieving secrets using secret stores refer to Setup Secret Store

Invoking Service Code Through Input Bindings

A developer who wants to trigger their app using an input binding can listen on a POST http endpoint with the route name being the same as metadata.name.

On startup Dapr sends a OPTIONS request to the metadata.name endpoint and expects a different status code as NOT FOUND (404) if this application wants to subscribe to the binding.

The metadata section is an open key/value metadata pair that allows a binding to define connection properties, as well as custom properties unique to the component implementation.

Examples

For example, here’s how a Python application subscribes for events from Kafka using a Dapr API compliant platform. Note how the metadata.name value kafkaevent in the components matches the POST route name in the Python code.

Kafka Component

  1. apiVersion: dapr.io/v1alpha1
  2. kind: Component
  3. metadata:
  4. name: kafkaevent
  5. namespace: default
  6. spec:
  7. type: bindings.kafka
  8. metadata:
  9. - name: brokers
  10. value: "http://localhost:5050"
  11. - name: topics
  12. value: "someTopic"
  13. - name: publishTopic
  14. value: "someTopic2"
  15. - name: consumerGroup
  16. value: "group1"

Python Code

  1. from flask import Flask
  2. app = Flask(__name__)
  3. @app.route("/kafkaevent", methods=['POST'])
  4. def incoming():
  5. print("Hello from Kafka!", flush=True)
  6. return "Kafka Event Processed!"

Binding endpoints

Bindings are discovered from component yaml files. Dapr calls this endpoint on startup to ensure that app can handle this call. If the app doesn’t have the endpoint, Dapr ignores it.

HTTP Request

  1. OPTIONS http://localhost:<appPort>/<name>

HTTP Response codes

CodeDescription
404Application does not want to bind to the binding
all othersApplication wants to bind to the binding

URL Parameters

ParameterDescription
appPortthe application port
namethe name of the binding

Note, all URL parameters are case-sensitive.

Binding payload

In order to deliver binding inputs, a POST call is made to user code with the name of the binding as the URL path.

HTTP Request

  1. POST http://localhost:<appPort>/<name>

HTTP Response codes

CodeDescription
200Application processed the input binding successfully

URL Parameters

ParameterDescription
appPortthe application port
namethe name of the binding

Note, all URL parameters are case-sensitive.

HTTP Response body (optional)

Optionally, a response body can be used to directly bind input bindings with state stores or output bindings.

Example: Dapr stores stateDataToStore into a state store named “stateStore”. Dapr sends jsonObject to the output bindings named “storage” and “queue” in parallel. If concurrency is not set, it is sent out sequential (the example below shows these operations are done in parallel)

  1. {
  2. "storeName": "stateStore",
  3. "state": stateDataToStore,
  4. "to": ['storage', 'queue'],
  5. "concurrency": "parallel",
  6. "data": jsonObject,
  7. }

Invoking Output Bindings

This endpoint lets you invoke a Dapr output binding. Dapr bindings support various operations, such as create.

See the different specs on each binding to see the list of supported operations.

HTTP Request

  1. POST/PUT http://localhost:<daprPort>/v1.0/bindings/<name>

HTTP Response codes

CodeDescription
200Request successful
500Request failed

Payload

The bindings endpoint receives the following JSON payload:

  1. {
  2. "data": "",
  3. "metadata": {
  4. "": ""
  5. },
  6. "operation": ""
  7. }

Note, all URL parameters are case-sensitive.

The data field takes any JSON serializable value and acts as the payload to be sent to the output binding. The metadata field is an array of key/value pairs and allows you to set binding specific metadata for each call. The operation field tells the Dapr binding which operation it should perform.

URL Parameters

ParameterDescription
daprPortthe Dapr port
namethe name of the output binding to invoke

Note, all URL parameters are case-sensitive.

Examples

  1. curl -X POST http://localhost:3500/v1.0/bindings/myKafka \
  2. -H "Content-Type: application/json" \
  3. -d '{
  4. "data": {
  5. "message": "Hi"
  6. },
  7. "metadata": {
  8. "key": "redis-key-1"
  9. },
  10. "operation": "create"
  11. }'

Common metadata values

There are common metadata properties which are support across multiple binding components. The list below illustrates them:

PropertyDescriptionBinding definitionAvailable in
ttlInSecondsDefines the time to live in seconds for the messageIf set in the binding definition will cause all messages to have a default time to live. The message ttl overrides any value in the binding definition.RabbitMQ, Azure Service Bus, Azure Storage Queue

Last modified February 16, 2021: Merge pull request #1235 from dapr/update-v0.11 (b4e9fbb)