Skip to end of banner
Go to start of banner

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

Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 12 Next »

002. Subscription resources (abonnementen) worden (standaard) door applicatie instanties aangevraagd, waarbij de Subscription.status op 'requested' wordt gezet. De volgende validatie moeten worden uitgevoerd:

a. criteria van het abonnement (Subscription.criteria), moet aan de lees (READ) criteria van de Autorisatie Matrix voldoen.

b. 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.

003. Na goedkeuring wordt de Subscription.status op 'active' gezet . 

004. De volgende runtime validaties MOETEN worden uitgevoerd, voordat de notificatie wordt verstuurd:

a. de criteria van het abonnement (Subscription.criteria), moet aan de lees (READ) criteria van de Autorisatie Matrix voldoen.

005. De ontvanger van het Post bericht (notificatie) MOET een beveiligd URL (httpsSubscription.channel.endpoint) beschikbaar stellen voor ontvangst per type notificatie.

006. In de notificatie wordt er geen payload (body) meegestuurd. De payload is NIET aanwezig in het abonnement (zie: Subscription.channel.payload)

007. Voor het verder specificeren van notificaties voor de ontvanger, adviseren we unieke headers te definiëren en toe te voegen, bij het gebruik van het versturen van notificaties. Alleen op deze manier kan men een notificatie correleren aan één Subscription resource instantie (abonnement)

008. De applicaties mag alleen zijn eigen abonnementen wijzigen en/of verwijderen.

009. Domein beheerders mogen abonnementen wijzigen en/of verwijderen.


Oude tekst

001. Een applicatie die het abonnement (Subscription resource) aanvraagt (requested), het registreren van een gebeurtenis, wordt de abonnement aanvrager genoemd.

002. Subscription resources (abonnementen) worden (standaard) door applicatie instanties aangevraagd, waarbij de Subscription.status op 'requested' wordt gezet. De volgende validatie moeten worden uitgevoerd:

a. criteria van het abonnement (Subscription.criteria), moet aan de lees (READ) criteria van de Autorisatie Matrix voldoen.

b. 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.

003. Na goedkeuring wordt de Subscription.status op 'active' gezet

004. De volgende runtime validaties MOETEN worden uitgevoerd, voordat de notificatie wordt verstuurd:

a. de criteria van het abonnement (Subscription.criteria), moet aan de lees (READ) criteria van de Autorisatie Matrix voldoen.

005. De ontvanger van het Post bericht (notificatie) MOET een beveiligd URL (httpsSubscription.channel.endpoint) beschikbaar stellen voor ontvangst per type notificatie.

006. In de notificatie wordt er geen payload (body) meegestuurd. De payload is NIET aanwezig in het abonnement (zie: Subscription.channel.payload)

007. Voor het verder specificeren van notificaties voor de ontvanger, adviseren we unieke headers te definiëren en toe te voegen, bij het gebruik van het versturen van notificaties. Alleen op deze manier kan men een notificatie correleren aan één Subscription resource instantie (abonnement)

008. De applicaties mag alleen zijn eigen abonnementen wijzigen en/of verwijderen.

009. Domein beheerders mogen abonnementen wijzigen en/of verwijderen.

  • No labels