You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently the "deliveryChannels" property is required when updating an asset, whether that be via a batch or PUT.
This keeps the logic in API simple but pushes the complexity to the API consumer. It's then more difficult to submit updates as you either need to know what delivery-channels have been configured or issue a GET first before constructing an update.
"deliveryChannels" should be optional for both create and update operations. To accommodate this we need a mechanism to allow delivery channels for an existing asset to be "re-defaulted". This mechanism is a new special channel, "default" (similar to the special "none" channel). When "none" channel is specified we place a marker in the database, however "default"doesn't place a marker but instead sets whatever the actual defaults are.
The possible scenarios are now:
"deliveryChannels": []: 400 bad request whether new or existing asset (consumer needs to be more explicit)
"deliveryChannels": [{ "channel: "none" }]: store 'none' marker in DB whether new or existing asset
"deliveryChannels": [ ..explicit, valid channels.. ]: use specified values
"deliveryChannels": null
If new asset use defaults
If existing asset, use delivery channels already configured for asset
"deliveryChannels": [{ "channel: "default" }]:
If new asset use defaults (equivalent to null)
If existing asset, reset to defaults (different from null)
Note that it's only the behaviour of the last 2 bullets that change - everything else is as-is but listing for completeness
The text was updated successfully, but these errors were encountered:
Currently the
"deliveryChannels"
property is required when updating an asset, whether that be via a batch or PUT.This keeps the logic in API simple but pushes the complexity to the API consumer. It's then more difficult to submit updates as you either need to know what delivery-channels have been configured or issue a GET first before constructing an update.
"deliveryChannels"
should be optional for both create and update operations. To accommodate this we need a mechanism to allow delivery channels for an existing asset to be "re-defaulted". This mechanism is a new special channel,"default"
(similar to the special"none"
channel). When"none"
channel is specified we place a marker in the database, however"default"
doesn't place a marker but instead sets whatever the actual defaults are.The possible scenarios are now:
"deliveryChannels": []
: 400 bad request whether new or existing asset (consumer needs to be more explicit)"deliveryChannels": [{ "channel: "none" }]
: store 'none' marker in DB whether new or existing asset"deliveryChannels": [ ..explicit, valid channels.. ]
: use specified values"deliveryChannels": null
"deliveryChannels": [{ "channel: "default" }]
:null
)null
)Note that it's only the behaviour of the last 2 bullets that change - everything else is as-is but listing for completeness
The text was updated successfully, but these errors were encountered: