Repository navigation
Feedback on managing subscriptions via api #1342
Description
I have just taken a look at the subscriptions api in particular the create subscription method and my current impression is that the data model should still undergo more reshaping so that we can end up with something similar to events.
Suggestions is that the request becomes:
| Property | Type | Description | Default | Required |
|---|---|---|---|---|
| id | string | |||
| Path | String | Where the event should be delivered to | No | |
| QueueUndeliverable | boolean | no | ||
| Priority | int | no | ||
| Lifespan | int | how long before a message should be discarded as it is now stale | no | |
| ClientId | string | who wants the events | No | |
| delivery mode | string | how the message should be delivered: binary,structured, batch etc | no | |
| Active | boolean | should the events be sent | true | no |
| AdditionalProperties | Array | the key & value of the additional properties | none | no |
| filters | array of filters | the filters which should be applied to check if the event is to be sent to the client with the check being done using globs | null | |
| filters[0].property | enum | can be subject, type, source or messageExpression | Yes | |
| filters[0].valueType | string | options like glob, sql etc | glob | yes |
| filters[0].value | string | a value to be used in the filter | yes |
The client api model should be
| Property | Type | Description | Default | Required |
|---|---|---|---|---|
| id | string | |||
| Destination | Uri | Where the event should be sent | Yes | |
| Path | String | Where the event should be delivered to | No | |
| QueueUndeliverable | boolean | false | no | |
| Priority | int | 1 | no | |
| Lifespan | int | how long before a message should be discarded as it is now stale | no | |
| ClientId | string | who wants the events | No | |
| Active | boolean | should the events be sent | true | no |
| authidentifer | string | No | ||
| authsecret | string | No | ||
| oauthdiscoverydoc | Uri | if empty auth assumed to be basic auth otherwise oauth | No | |
| AdditionalProperties | Array | the key & value of the additional properties | none | no |
We should have seperate api endpoints to create/manage clients so that they can be reused across subscriptions.
Bindings should be written for the different transports.
Activity
[-]Feedback on subscription api.[/-][+]Feedback on managing subscriptions[/+][-]Feedback on managing subscriptions[/-][+]Feedback on managing subscriptions via api[/+]duglin commentedon May 14, 2025
ping @clemensv
clemensv commentedon May 20, 2025
The subscription API is intentionally quite loose in how it defines event sinks.
Adding a deliverymode switch is a good idea. We've had quite a few discussions about protocol/envelope configurations in xRegistry and should bring those here, including moving the target endpoint into the protocol-specific section.
thompson-tomo commentedon May 21, 2025
Ok, I really am not a fan of
As That seems to be contradictory to the interoperability achieved with cloud events messages hence my proposal for being able to specify the path in an agnostic way via #1346.