- Een applicatie die het abonnement (Subscription resource) aanvraagt (requested), het registreren van een gebeurtenis, wordt de abonnement aanvrager genoemd.
- Subscription resources (abonnementen) worden (standaard) door (domein) beheerders aangevraagd, via het beheerportaal (rol), waarbij de
Subscription.status
op 'requested
' wordt gezet. Zie: "Het specificeren van de toegang". - De (domein) beheerders MOETEN het abonnement valideren. Na goedkeuring wordt de
Subscription.status
op 'active
' gezet . - De volgende validaties MOETEN worden uitgevoerd:
- de criteria van het abonnement (
Subscription.criteria
), wanneer een notificatie verstuurd MOET worden en of de abonnement aanvrager geautoriseerd is om deze criteria te mogen aanvragen - de reden (
Subscription.reason
) waarom een afnemer het abonnement wil hebben MOET door de (domein)beheerder vastgelegd worden in het abonnement. - Voor Koppeltaal 2.0 wordt alleen het '
rest-hook
' kanaal gebruikt (zie:Subscription.channel.type
). Dit kanaal wordt gebruikt door een Post bericht (notificatie) naar een URL (Subscription.channel.endpoint
) te sturen. - De beschikbaarheid en toegankelijkheid van het endpoint, de
Subscription.channel.endpoint
MOET gevalideerd worden.
- de criteria van het abonnement (
- De ontvanger van het Post bericht (notificatie) MOET een URL (
Subscription.channel.endpoint
) beschikbaar stellen voor ontvangst per type notificatie. - De URL moet niet herleidbaar en raadbaar zijn naar een notificatie type (security eis).
- In de notificatie wordt er geen payload (body) meegestuurd. De payload is NIET aanwezig in het abonnement (zie:
Subscription.channel.payload
) - Voor het verder specificeren van notificaties voor de ontvanger, raden we aan headers te definiëren en toe te voegen, bij het gebruik van het versturen van notificaties. (zie voorbeeld:
Subscription.channel.header:"X-KT_Subscription:UpdateTask"
) - Optioneel: Alleen (domein) beheerders, via het beheerportaal, kan abonnementen wijzigen en/of verwijderen.
...