- 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 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.
{} |
