Het verenigingstype is een parameter die bepaalt welke verenigingen zich kunnen registreren in het Verenigingsregister. Verder bepaalt de parameter de hoedanigheid van acties die een vereniging in het Verenigingsloket kan uitvoeren. De parameter is daarom van belang binnen het Verenigingsloket. Binnen de huidige context beantwoordt ze volgende vraag, "Is een verening registreerbaar?"
Het Verenigingsloket vereist de gebruiker om zich te authenticeren en een keuze te maken tussen de verenigingen waartoe hij/zij behoort. Na het authenticeren, ontvangt de gebruiker een token met daarin de vereniging: naam, KBO-nummer, eventueel de V-code en het verenigingstype. Ontbreekt de V-code, dan kan de gebruiker de vereniging registeren.
Om de claim verenigingstype aan te leveren, dient ACM/IDM een extra request uit te voeren naar het VKBO. ACM/IDM wenst dit request naar het VKBO niet meer uit te voeren. Ze wensen af van deze trage(?) dependency. Het KBO-nummer en de naam van de verening ontvangt ACM/IDM van het KBO. Dit laatste endpoint wenst ACM/IDM nog steeds te gebruiken.
Het Verenigingsloket heeft het verenigingstype nodig om de user flow te bepalen, o.a. bij het al dan niet kunnen registreren van een vereniging. De te nemen beslissing is: wie geeft deze informatie door aan wie?
Het Verenigingsloket (Departement Jeugd, Cultuur en Media) stelde de vraag of het Verenigingsregister een REST endpoint kan ontwikkelen dat een KBO-nummer aanvaardt en antwoordt met het verenigingstype. Dit endpoint zou dan kunnen worden opgeroepen door ACM/IDM.
Voordelen:
- Het Verenigingsloket ontvangt bij authenticatie zowel de naam, het KBO-nummer én het verenigingstype van ACM/IDM. Er zijn geen extra requests nodig vanuit het Vereningsloket.
Nadelen en risico's:
- ACM/IDM neemt een (extra) dependency op het Verenigingsregister.
- ACM/IDM neemt verantwoordelijkheid voor een claim die niet zuiver haar verantwoordelijkheid. M.a.w. dient het verenigingstype een claim te zijn?
- Het risico bestaat dat op termijn andere toepassingen ook deze claim wensen te ontvangen. In dit geval wordt de dependency tussen ACM/IDM en het Vereningsregister groter. De claim en dus het nieuwe endpoint worden gebruikt binnen uses cases anders dan de oorspronkelijke.
- Het Verenigingsregister is geen owner van (V)KBO data. Voor de huidige use case kan het Verenigingsregister per ontvangen request het VKBO bevragen. Dit houdt in dat het register afhankelijk is van de uptime én performantie van het VKBO. Indien de uptime en/of performantie te wensen overlaten, kan authenticatie falen of een verwachte claim ontbreken. Het Verenigingsregister zou om voorafgaande te voorkomen de VKBO data kunnen cachen. Maar in dit geval wordt de correctheid van de claim potentieel verzwakt daar deze out-of-date kan zijn.
Het Verenigingsloket bevraagt het VKBO rechtstreeks.
Voordelen:
- Het loket behoudt zelf de controle over hoe ze VKBO data ter beschikking heeft. Bijv. VKBO per request bevragen of VKBO data cachen (en het refresh rate van de cache).
- Het loket bepaalt zelf de snelheid waarin de nieuwe functionaliteit ontwikkelt kan worden.
Nadelen en risico's:
Het Vereningsregister stelt een nieuw endpoint ter beschikking dat een KBO-nummer aanvaardt en met volgende informatie antwoordt:
- Is de vereniging registreerbaar?
- Ja, indien het verenigingstype dit toelaat én de vereniging nog niet geregistreerd is.
- Nee, in alle andere gevallen.
- Het Verenigingstype
- V-Code indien gekend
Bijv.
{ "isRegistreerbaar": false, "vereningstype": "vzw" "v-code": "123" }