State management API reference

Detailed documentation on the state management API

Component file

A Dapr State Store component yaml file has the following structure:

apiVersion: dapr.io/v1alpha1
kind: Component
metadata:
  name: <NAME>
  namespace: <NAMESPACE>
spec:
  type: state.<TYPE>
  metadata:
  - name:<KEY>
    value:<VALUE>
  - name: <KEY>
    value: <VALUE>

The metadata.name is the name of the state store.

the spec/metadata section is an open key value pair metadata that allows a binding to define connection properties.

Starting with 0.4.0 release, support for multiple state stores was added. This is a breaking change from previous releases as the state APIs were changed to support this new scenario.

Please refer https://github.com/dapr/dapr/blob/master/docs/decision_records/api/API-008-multi-state-store-api-design.md for more details.

Key scheme

Dapr state stores are key/value stores. To ensure data compatibility, Dapr requires these data stores follow a fixed key scheme. For general states, the key format is:

<App ID>||<state key>

For Actor states, the key format is:

<App ID>||<Actor type>||<Actor id>||<state key>

Save state

This endpoint lets you save an array of state objects.

HTTP Request

POST http://localhost:<daprPort>/v1.0/state/<storename>

URL Parameters

Note, all URL parameters are case-sensitive.

Request Body

A JSON array of state objects. Each state object is comprised with the following fields:

ETag format Dapr runtime treats ETags as opaque strings. The exact ETag format is defined by the corresponding data store.

HTTP Response

Response Codes

Response Body

None.

Example

curl -X POST http://localhost:3500/v1.0/state/starwars \
  -H "Content-Type: application/json" \
  -d '[
        {
          "key": "weapon",
          "value": "DeathStar"
        },
        {
          "key": "planet",
          "value": {
            "name": "Tatooine"
          }
        }
      ]'

Get state

This endpoint lets you get the state for a specific key.

HTTP Request

GET http://localhost:<daprPort>/v1.0/state/<storename>/<key>

URL Parameters

Note, all URL parameters are case-sensitive.

HTTP Response

Response Codes

Response Headers

Response Body

JSON-encoded value

Example

curl http://localhost:3500/v1.0/state/starwars/planet \
  -H "Content-Type: application/json"

The above command returns the state:

{
  "name": "Tatooine"
}

To pass metadata as query parammeter:

GET http://localhost:3500/v1.0/state/starwars/planet?metadata.partitionKey=mypartitionKey

Get bulk state

This endpoint lets you get a list of values for a given list of keys.

HTTP Request

POST http://localhost:<daprPort>/v1.0/state/<storename>/bulk

URL Parameters

Note, all URL parameters are case-sensitive.

HTTP Response

Response Codes

Response Body

An array of JSON-encoded values

Example

curl http://localhost:3500/v1.0/state/myRedisStore/bulk \
  -H "Content-Type: application/json" \
  -d '{
          "keys": [ "key1", "key2" ],
          "parallelism": 10,
      }'

The above command returns an array of key/value objects:

[
  {
    "key": "key1",
    "data": "value1",
    "etag": "1"
  },
  {
    "key": "key2",
    "data": "value2",
    "etag": "1"
  },
]

To pass metadata as query parammeter:

POST http://localhost:3500/v1.0/state/myRedisStore/bulk?metadata.partitionKey=mypartitionKey

Delete state

This endpoint lets you delete the state for a specific key.

HTTP Request

DELETE http://localhost:<daprPort>/v1.0/state/<storename>/<key>

URL Parameters

Note, all URL parameters are case-sensitive.

Request Headers

HTTP Response

Response Codes

Response Body

None.

Example

curl -X "DELETE" http://localhost:3500/v1.0/state/starwars/planet -H "ETag: xxxxxxx"

State transactions

Persists the changes to the state store as a multi-item transaction.

Note that this operation is dependant on a using state store component that supports multi-item transactions.

List of state stores that support transactions:

• Redis
• MongoDB
• PostgreSQL
• SQL Server
• Azure CosmosDB

HTTP Request

POST/PUT http://localhost:<daprPort>/v1.0/state/<storename>/transaction

HTTP Response Codes

URL Parameters

Note, all URL parameters are case-sensitive.

Request Body

Each state operation is comprised with the following fields:

Examples

curl -X POST http://localhost:3500/v1.0/state/starwars/transaction \
  -H "Content-Type: application/json" \
  -d '{
        "operations": [
          {
            "operation": "upsert",
            "request": {
              "key": "key1",
              "value": "myData"
            }
          },
          {
            "operation": "delete",
            "request": {
              "key": "key2"
            }
          }
        ],
        "metadata": {
          "partitionKey": "planet"
        }
      }'

Configuring state store for actors

Actors don’t support multiple state stores and require a transactional state store to be used with Dapr. Currently Mongodb, Redis, PostgreSQL, SQL Server, and Azure CosmosDB implement the transactional state store interface. To specify which state store to be used for actors, specify value of property actorStateStore as true in the metadata section of the state store component yaml file. Example: Following components yaml will configure redis to be used as the state store for Actors.

apiVersion: dapr.io/v1alpha1
kind: Component
metadata:
  name: statestore
  namespace: default
spec:
  type: state.redis
  metadata:
  - name: redisHost
    value: <redis host>
  - name: redisPassword
    value: ""
  - name: actorStateStore
    value: "true"

Optional behaviors

Key scheme

A Dapr-compatible state store shall use the following key scheme:

• <App ID>||<state key> key format for general states
• <App ID>||<Actor type>||<Actor id>||<state key> key format for Actor states.

Concurrency

Dapr uses Optimized Concurrency Control (OCC) with ETags. Dapr makes optional the following requirements on state stores:

• An Dapr-compatible state store may support optimistic concurrency control using ETags. When an ETag is associated with an save or delete request, the store shall allow the update only if the attached ETag matches with the latest ETag in the database.
• When ETag is missing in the write requests, the state store shall handle the requests in a last-write-wins fashion. This is to allow optimizations for high-throughput write scenarios in which data contingency is low or has no negative effects.
• A store shall always return ETags when returning states to callers.

Consistency

Dapr allows clients to attach a consistency hint to get, set and delete operation. Dapr support two consistency level: strong and eventual, which are defined as the follows:

Eventual Consistency

Dapr assumes data stores are eventually consistent by default. A state should:

• For read requests, the state store can return data from any of the replicas
• For write request, the state store should asynchronously replicate updates to configured quorum after acknowledging the update request.

Strong Consistency

When a strong consistency hint is attached, a state store should:

• For read requests, the state store should return the most up-to-date data consistently across replicas.
• For write/delete requests, the state store should synchronisely replicate updated data to configured quorum before completing the write request.

Example

The following is a sample set request with a complete operation option definition:

curl -X POST http://localhost:3500/v1.0/state/starwars \
  -H "Content-Type: application/json" \
  -d '[
        {
          "key": "weapon",
          "value": "DeathStar",
          "etag": "xxxxx",
          "options": {
            "concurrency": "first-write",
            "consistency": "strong",
          }
        }
      ]'

Next Steps

• State management overview
• How-To: Save & get state

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