Eisen (en aanbevelingen) van het registreren en signaleren van gebeurtenissen

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:
1. 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
2. de reden (Subscription.reason) waarom een afnemer het abonnement wil hebben MOET door de (domein)beheerder vastgelegd worden in het abonnement.
3. 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.
4. De beschikbaarheid en toegankelijkheid van het endpoint, de Subscription.channel.endpoint MOET gevalideerd worden.
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.