From 1223d5cd736e136f86e08921a49205199b53883b Mon Sep 17 00:00:00 2001 From: Artur Souza Date: Fri, 15 Jan 2021 15:51:37 -0800 Subject: [PATCH] Fix doc. --- .../pubsub/pubsub-message-ttl.md | 2 +- .../content/en/reference/api/pubsub_api.md | 28 +++++++++---------- 2 files changed, 15 insertions(+), 15 deletions(-) diff --git a/daprdocs/content/en/developing-applications/building-blocks/pubsub/pubsub-message-ttl.md b/daprdocs/content/en/developing-applications/building-blocks/pubsub/pubsub-message-ttl.md index 542142512..6ce9454e4 100644 --- a/daprdocs/content/en/developing-applications/building-blocks/pubsub/pubsub-message-ttl.md +++ b/daprdocs/content/en/developing-applications/building-blocks/pubsub/pubsub-message-ttl.md @@ -10,7 +10,7 @@ description: "Use time-to-live in Pub/Sub messages." Dapr enables per-message time-to-live (TTL). This means that applications can set time-to-live per message, and subscribers will not receive those messages after expiration. -All Dapr [pub/sub components]({{< ref supported-pubsub >}}) are compatible with message TTL, as Dapr handles the TTL logic within the runtime. +All Dapr [pub/sub components]({{< ref supported-pubsub >}}) are compatible with message TTL, as Dapr handles the TTL logic within the runtime. Simply set the `ttlInSeconds` metadata when publishing a message. In some components, such as Kafka, time-to-live can be configured in the topic via `retention.ms` as per [documentation](https://kafka.apache.org/documentation/#topicconfigs_retention.ms). With message TTL in Dapr, applications using Kafka can now set time-to-live per message in addition to per topic. diff --git a/daprdocs/content/en/reference/api/pubsub_api.md b/daprdocs/content/en/reference/api/pubsub_api.md index 3cbfd2e55..3a1e29626 100644 --- a/daprdocs/content/en/reference/api/pubsub_api.md +++ b/daprdocs/content/en/reference/api/pubsub_api.md @@ -14,7 +14,7 @@ Dapr guarantees at least once semantics for this endpoint. ### HTTP Request ``` -POST http://localhost:/v1.0/publish// +POST http://localhost:/v1.0/publish//[?] ``` ### HTTP Response codes @@ -31,8 +31,9 @@ Code | Description Parameter | Description --------- | ----------- daprPort | the Dapr port -pubsubname | the name of pubsub component. +pubsubname | the name of pubsub component topic | the name of the topic +metadata | query parameters for metadata as described below > Note, all URL parameters are case-sensitive. @@ -44,6 +45,16 @@ curl -X POST http://localhost:3500/v1.0/publish/pubsubName/deathStarStatus \ }' ``` +#### Metadata + +Metadata can be sent via query parameters in the request's URL. It must be prefixed with `metadata.` as shown below. + +Parameter | Description +--------- | ----------- +metadata.ttlInSeconds | the number of seconds for the message to expire as [described here]({{< ref pubsub-message-ttl.md >}}) + +> Additional metadata parameters are available based on each pubsub component. + ## Optional Application (User Code) Routes ### Provide a route for Dapr to discover topic subscriptions @@ -89,7 +100,7 @@ The following example illustrates this point, considering a subscription for top #### HTTP Request ``` -POST http://localhost:/[?] +POST http://localhost:/ ``` > Note, all URL parameters are case-sensitive. @@ -100,17 +111,6 @@ Parameter | Description --------- | ----------- appPort | the application port path | route path from the subscription configuration -metadata | query parameters for metadata as described below - -##### Metadata - -Metadata can be sent via query parameters in the request's URL. It must be prefixed with `metadata.` as shown below. - -Parameter | Description ---------- | ----------- -metadata.ttlInSeconds | the number of seconds for the message to expire as [described here]({{< ref pubsub-message-ttl.md >}}) - -> Additional metadata parameters can be available based on each pubsub component. #### Expected HTTP Response