Feedback on managing subscriptions via api

[thompson-tomo]

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.

[duglin]

ping @clemensv

[clemensv]

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]

Ok, I really am not a fan of

moving the target endpoint into the protocol-specific section.

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.