2.1 Visie
2.1.1 Data en het nut van API's
De overheid gebruikt data voor het oplossen van maatschappelijke vraagstukken en opgaven zoals in wonen, stikstof, de energietransitie, armoede, schulden en zorg. Met API's zijn we in staat een platform van data te laten ontstaan waarop we de maatschappelijke vraagstukken en dienstverlening organiseren. Het bedrijfsleven en grote internetplatforms maken al volop gebruik van API's om data flexibel te ontsluiten.
Het gebruik van API's maakt een een onstuimige groei door. Steeds meer organisaties bieden API's aan en veel organisaties bieden steeds meer API's aan. API's bieden de overheid de kans om data snel, eenvoudig en in real-time aan te bieden. De samenleving verwacht een open overheid. Dat kan met API's. De data die de overheid voor het uitvoeren van haar taken verzamelt, wordt nu al voor hergebruik beschikbaar gemaakt. Nu wordt data nog vaak als bestand beschikbaar gemaakt waarbij het aan de gebruiker is de data te vinden, binnen te halen en te verwerken. Met API's wordt data steeds bij de bron opgehaald, pas wanneer de data nodig is. Met API's kan data heel toegespitst op een vraag verstrekt worden, waardoor bovenmatige verstrekking van data wordt voorkomen (dataminimalisatie). Met API's is het eenvoudiger het datagebruik te verantwoorden. Door al deze voordelen maken API's nieuwe toepassingen met data mogelijk voor burgers.
2.1.3 Afspraken en standaardisatie API’s sleutel tot succes
De API Strategie van de Nederlandse overheid bevat afspraken en standaarden om API’s te ontwerpen, te beveiligen, toegankelijk te maken en te gebruiken. Zo zijn API’s door afspraken over de publicatie van de specificaties voor afnemers op een uniforme en voorspelbare manier vindbaar. En zijn API’s door afspraken en standaarden over authenticatie, autorisatie, logging en andere specificaties beter en op een uniforme manier toegankelijk en bruikbaar. Het gebruik van de afspraken en standaarden door aanbieders vergemakkelijkt het gebruik van API’s voor afnemers. Dit geeft aanbieders het vertrouwen dat hun API’s door afnemers op een bekende voorspelbare manier te gebruiken zijn. Daarnaast maken afspraken en standaarden het mogelijk om aan te geven of API’s aan minimumvereisten voldoen. Daarmee neemt het vertrouwen van afnemers in de kwaliteit van API’s toe. Zo voorkomen we dat de manier van datadeling op verschillende manieren wordt ingericht.
Nu het gebruik van API’s in opmars is, is het van belang de gemaakte afspraken toe te passen. Voor zover verdere afspraken nodig zijn, werken we samen in de Werkgroepen van het Kennisplatform API's.
2.2 API first Strategie
De API first strategie past binnen de huidige beleidsdoelen en de omgeving van de publieke sector. Voor uit te leggen wat API first inhoud lichten we eerst deze beleidsdoelen en de omgeving (vanuit API's bezien) toe. Daarna volgt wat API first inhoud en drie concrete acties die er uit af te leiden zijn.
2.2.1 Beleidsdoelen
Om de beleidsdoelen van de overheid te halen is doorontwikkeling van de digitale overheid van groot belang. API koppelvlakken kunnen hierin een rol spelen om informatie eenvoudig en veilig uit te wisselen tussen overheden onderling en tussen overheden en burgers of bedrijven.
Een aantal beleidsdoelen waarin API's een rol kunnen spelen (met het voor API's relevante sleutelwoord in cursief) zijn:
- Transparante overheid. In het kader van de Wet Open Overheid wil de overheid ondermeer hergebruik van open data stimuleren. Zie ook de Open Data Directive van de EU.
- Regie op gegevens. Hierbij is het doel om burgers en bedrijven te ondersteunen bij regie op hun gegevens, die door de overheid verzameld en gebruikt worden. Dit resulteert in een sector-overstijgend kader dat veilige, betrouwbare en gebruiksvriendelijke digitale uitwisseling van gegevens tussen overheden, private en maatschappelijke organisaties mogelijk maakt. Veiligheid en betrouwbare gegevensuitwisseling kan worden gewaarborgd door toepassing van de API Design Rules.
- Digitale inclusie Door gegevens via een API first strategie openbaar te maken kunnen gedifferentieerde gebruikersinterfaces die voor minder digitaal vaardige burgers bruikbaar zijn.
- De Interbestuurlijke Data Strategie (IBDS) is het resultaat van nauwe samenwerking tussen departementen, uitvoeringsorganisaties en koepels van medeoverheden. Het programma zorgt ervoor dat het makkelijker wordt om binnen de overheid verantwoord met data te werken. Een van de speerpunten van het IBDS is het ontwikkelen van overheidsbrede systeemfuncties waaronder een federatief datastelsel waarmee data beter vindbaar en technisch uitwisselbaar wordt.
- EU Data Act of Datawet De datawet is gericht op eerlijke toegang tot en het gebruik van gegevens. Hierbij worden met name Internet of Things (IoT) apparaten genoemd en middelen voor openbare lichamen om toegang te krijgen tot gegevens die in het bezit zijn van de particuliere sector. De datawet maakt deel uit van de Europese datastrategie.
Voor al deze beleidsdoelen geldt dat API's er een rol in kunnen spelen maar dat de API standaarden en best practices er nog niet altijd in beeld zijn.
2.2.2 Omgeving
Tot de omgeving van een publieke organisatie hoort iedereen die interactie heeft of wil hebben met een publieke organisatie. Burger, bedrijf, ketenpartner of andere organisaties uit de publieke sector. De omgeving van een organisatie uit de publieke sector is al jaren bekend met API's en de toepassing ervan. Zo herkent iedere burger hoe eenvoudige verschillende platforms uit de platform economie (Google Amazon Linkedin Meta) eenvoudig elkaars functionaliteit integreren. Denk aan de store in store concepten op bij grote online retailers, knoppen om informatie te delen op je favoriete sociale medium.
Het bedrijfsleven weet hoe via PSD2 de functionaliteit en data van de bankwereld via API's is opengebroken en interoperabel gemaakt is. Men weet ook hoe functionaliteit als betalingen, klantrelatiesystemen, boekhoudpakketten en salaris administratie middels API's met elkaar te integreren zijn.
De grootste kennis in de markt van (potentiële) software leveranciers in de publieke sector voor het verbinden van IT systemen ligt mede om bovengenoemde redenen bij API's.
In de publieke sector zelf zijn API's in sommige sectoren ook al dominant, CBS ontsluit al haar statistische informatie al meer dan 10 jaar via API's, het digitaal stelsel omgevingswet heeft ze van begin af aan omarmt, het KNMI en het Kadaster en vele anderen bieden hun open data via API's aan zodat anderen deze kunnen hergebruiken.
API's pas je dus toe om goed aan te sluiten op de verwachtingen van je omgeving.
Niet alle organisaties zijn zo ver, sommige cruciale bedrijfsprocessen draaien nog op oude (maar meestal ook zeer stabiele) systemen die bedacht zijn voordat API's gemeengoed werden in de IT. Je zal hen moeten blijven bedienen tot zij de omslag hebben kunnen maken. Die omslag maken is vaak niet eenvoudig, in de bankwereld was er de PSD2 wetgeving nodig om dit te laten gebeuren.
In de gemeentelijk wereld wordt deze omslag gemaakt in het common ground initiatief. Net als bij PSD2 worden API's ook bij common ground ingezet als transitie mechanisme. API's worden gebruikt om in stappen over te gaan naar nieuwe manier van werken waarbij API's het ontkoppelpunt vormen.
2.2.3 API first
Tot de omgeving van een publieke organisatie hoort iedereen die interactie heeft of wil hebben met een publieke organisatie. Burger, bedrijf, ketenpartner of andere organisaties uit de publieke sector.
De omgeving van organisaties in de publieke sector bedien je het best door hen de mogelijkheid te geven zoveel mogelijk op hun eigen voorwaarden gebruik te maken van data en functionaliteit die je als publieke organisatie aanbied.
Je moet ze dus niet dwingen om één kanaal te gebruiken. Tegenwoordig zijn er veel kanalen om functionaliteit en data & functionaliteit langs te ontsluiten:
- Websites,
- Mobiele Apps,
- Computer applicaties,
- IoT devices,
- Fysieke loketten,
- Brievenpost
Achter al deze ontsluitingskanalen zit een IT systeem. Het is in de huidige digitale samenleving niet reëel om al je kanalen volledig zelf in de hand te hebben. Door direct toegang te geven tot data en functionaliteit middels een API biedt je de mogelijkheid om deze via verschillende kanalen aan te bieden. Je kan voor ieder kanaal afwegen of je dat als organisatie zelf aanbied of dit aan een andere partij laat. Je opereert dus "API first": Altijd is er een goed gedocumenteerde machine interface die aan de omgeving ter beschikking gesteld kan worden. voor de kanalen die je zelf direct bedient (bijvoorbeeld een website) maak je gebruik van diezelfde interface. Het geeft je omgeving de mogelijkheid om daar waar er voor hen geen geschikt kanaal bestaat, dit zelf te maken, als ook om nieuwe mogelijkheden te ontdekken die je zelf nog niet had bedacht. Wanneer je de API met iedereen deelt geeft het ook je gehele omgeving in de basis een gelijke informatiepositie. De API first strategie is in lijn met het NORA principe "bouw diensten modulair op" en de bijbehorende implicatie "wissel gegevens tussen (web)applicaties uit met API's". Zoals Common ground en PSD2 laten zien is API first niet alleen een voorwaarde voor moderne IT systemen, het toepassen ervan is ook een middel voor modernisering.
2.2.4 Actie 1: Houdt regie door open API standaarden toe te passen
API's vormen bij de grote platforms van de IT wereld, maar ook al bij nationale leveranciers een essentieel onderdeel van hun strategie. In de relatie met de markt houdt je als overheid de regie door zelf te bepalen hou informatie middels open API standaarden wordt uitgewisseld. Samenwerking met de markt op basis van open standaarden is wenselijk. Samenwerking op basis van leveranciers eigen oplossingen onder voorwaarden van die leverancier is (hoewel op korte termijn soms aantrekkelijk) op de lange termijn zeer risicovol. Vanwege de kans op "vendor lock-in" maar misschien nog wel meer vanwege de mogelijkheid dat we als publieke sector de controle verliezen over wat er met gevoelige informatie die wij bijhouden gebeurd. Met name als die bij de grote platforms terecht komen. De samenleving verwacht van organisaties in de publieke sector dat we zorgvuldig met hun gegevens omgaan. Het gebruik van niet open standaarden voor gegevensuitwisseling past daar niet bij.
2.2.5 Actie 2: Druk kosten door API standaarden toe te passen
Als organisatie uit de publieke sector druk je kosten door zoveel mogelijk gebruik te maken van dat wat brede marktondersteuning heeft. Dan zijn er meer partijen die je kunnen helpen, is er meer personeel te vinden met de benodigde kennis en meer keuze betekent meer concurrentie en dus lagere kosten. Kennis over API's in momenteel zeer breed in de markt beschikbaar. Breder dan nog regelmatig toegepaste alternatieven als SOAP XML(WUS/ ebMS koppelvlakken van Digikoppeling). Het is dus logisch om hier op in te zetten, tegelijkertijd is het goed om innovaties goed te volgen. Dit is eenvoudig te volgen via de lijsten met verplichte en veelgebruikte standaarden van het forum standaardisatie. Daarin is te vinden dat er de REST API Design rules zijn evenals een (daarop aansluitend) REST API profiel binnen Digikoppeling. Gebruik de standaarden bij inkoop voor nieuwbouw en verbouw van IT systemen.
Het volgen van standaarden als de REST API design rules is in het belang van de kosten van de overheid in zijn geheel omdat breed gebruik van de standaard interoperabiliteit, wendbaarheid en bijkomende kostenvoordeel voor de hele publieke sector bewerkstelligt.
2.2.6 Actie 3: Deel Kennis over toepassen van API's
Je staat als organisatie in de publieke sector in de uitvoering nooit alleen. Je maakt de functionaliteit niet alleen, je werkt altijd in een keten met andere overheden en niet overheden. De kern van de samenwerking zit voor een significant deel in de koppeling. Daarom is het op een uniforme manier aanpakken van de API's die daar invulling aan geven van belang. Als organisatie in de publieke sector deel je kennis over hoe je dat doet met de hele publieke sector en maakt waar mogelijk hergebruik van wat anderen al hebben gemaakt. Voor API's doen we dat binnen het kennisplatform API's. Daar maken we standaarden en best practices die we met elkaar delen. Het gaat hier om standaarden voor uniformiteit, en interoperabiliteit van API's, maar ook voor over ontwerpkeuzes binnen API's, voor de IT architectuur waarbinnen ze gebruikt worden als ook over de vindbaarheid van API's. We streven ernaar deze binnen bestaande gremia zoals de lijst verplichte standaarden van het forum standaardisatie voor standaarden en de NORA voor architectuur vast te stellen.
2.2.7 Actie 4: Zorg dat API's vindbaar zijn
Het is niet alleen belangrijk om API's aan te bieden, ze moeten ook door de omgeving gevonden kunnen worden.
Het is belangrijk om een balans te vinden tussen vindbaarheid en vereiste inspanning om alle publieke informatie op verschillende plekken actueel te houden.
Vindbaarheid verhoog je door het voor makers van API's zo laagdrempelig mogelijk te maken om API's te publiceren.
Praktisch zijn er, afhankelijk van de ambitie en middelen van een organisatie, meerdere manieren voor. Je kan een eigen developer portaal bouwen waar je API's ontsluit toegang regelt (indien nodig) en zorgt voor goede documentatie. Je kan ook hergebruik maken van de catalogi en portalen die de overheid biedt.
We werken als publieke sector aan afspraken (zoals in het Federatief Data Stelsel) om de vindbaarheid van API's in catalogi en portalen te vergroten waarbij het streven is dat informatie over API's eenmalig door de aanbieder wordt aangeleverd en in meerdere catalogi en portalen kan worden hergebruikt.
API's moeten waar mogelijk (binnen grenzen openbaarheid) centraal en publiekelijk vindbaar zijn, dus niet alleen via de kanalen van de aanbiedende organisatie maar ook vanuit landelijke portalen/catalogi.
2.3 Intentieverklaring API strategie
In onze visie zal de digitale overheid de komende jaren steeds meer veilig en efficiënt data uitwisselen door applicaties zoveel mogelijk te scheiden van de data, en deze data bij de bron te bewaren. Voorzieningen gaan data ophalen bij de bron zodra deze nodig is. Om deze data-uitwisseling mogelijk te maken, zijn platformen, API's en verplichte standaarden onmisbaar. Hiermee biedt de overheid toegang tot evenwichtige en consistente data sets, onafhankelijk van de complexiteit van achterliggende systemen, voor burgers, bedrijven en ketenpartners van de overheid.
Met deze intentieverklaring, verklaart onze organisatie dat wij de volgende afspraken tussen de deelnemers van het Kennisplatform API's zullen naleven:
In lijn met de API first strategie bij te dragen aan modernisering van de IT voorzieningen in de overheid
Deelnemers aan het Kennisplatform API's leveren een actieve bijdrage aan standaardisatie van het gebruik van API's in en buiten het Kennisplatform API's.
We houden ons aan de API standaarden die we samen hebben ontwikkeld welke op de lijst verplichte standaarden van het forum standaardisatie staan, zoals de REST API Design Rules voor het aanbieden van RESTful API's en het NL GOV Assurance Profile for OAuth 2.0 voor autorisatie op API's waar door gebruikers rechtendelegatie kan worden toegepast.
De overheid registreert haar extern toegankelijke REST API's bij een centraal vindbare openbare catalogus, tenzij dit om beveiligingsredenen niet gewenst is. Zo kunnen ontwikkelaars de API's van de overheid altijd vinden.
2.4 Praktijkvoorbeelden
2.4.1 De API op de Basisregistratie Personen (BRP) van Haal Centraal
Persoonsgegevens uit de Basisregistratie Personen (BRP) worden nu vaak gesynchroniseerd met een lokale kopiedatabase bij een gemeente. In de processen van de gemeente wordt dan die kopiedatabase bevraagd in processen waar persoonsgegevens nodig zijn. Binnen het programma Haal Centraal experimenteert de Rijksdienst voor Identiteitsgegevens (RvIG), de vijf grote gemeenten (Amsterdam, Den Haag, Eindhoven, Rotterdam en Utrecht) en VNG Realisatie met een API waarmee gemeenten in hun werkprocessen direct de Basisregistratie Personen (BRP) kunnen bevragen. In totaal 10 gemeenten gaan deze API gebruiken en beproeven in een pilot.
Over de voordelen van de BRP API heeft Haal Centraal een heldere video gemaakt. De specificatie van de API uit de pilot is te vinden op Github repository van VNG. Wanneer de pilot slaagt, komt mogelijk een API beschikbaar voor alle gemeenten en andere overheidsorganisaties die de BRP nu via het huidige berichtenverkeer raadplegen.
2.4.2 De API voor Zaakgericht Werken van Common Ground
Veel gemeenten werken zaakgericht. Dit betekent dat informatie over dienstverlening aan inwoners in zaken is geordend in een zaaksysteem.
Deze manier van werken richt zich op het transparant afhandelen van een samenhangende hoeveelheid werk (een 'zaak'), welke een duidelijk omschreven aanleiding kent (bijvoorbeeld een aanvraag) en leidt tot een duidelijk omschreven resultaat.
ICT systemen ondersteunen zaakgericht werken met als voordelen het automatische termijnbewaking en routeren van taken naar betrokken medewerkers of systemen.
Met daarbij ook het parallel kunnen uitvoeren van samenhangende taken, geautomatiseerd toekennen van metadata en het duurzaam toegankelijk bewaren van het zaakdossier. De API-standaarden voor zaakgericht werken helpen bij het (ont)koppelen van zaaksystemen en de registers waar documenten en overige informatie in zijn opgeslagen. Als alle gemeenten de API-standaarden voor zaakgericht werken gebruiken, wordt de uitwisseling van gegevens voor deze systemen efficiënter. Het is bovendien een belangrijke stap in het realiseren van Common Ground, iets waar alle gemeenten naar streven.
2.4.3 De API voor Basisregistratie Kadaster (BRK) - Publiekrechtelijke Beperkingen
De Wet kenbaarheid publiekrechtelijke beperkingen onroerende zaken (Wkpb) geeft inzicht in door de overheid opgelegde beperkingen op een stuk grond of een daarop staand gebouw. Sinds 2021 is de vernieuwde Wet kenbaarheid publiekrechtelijke beperkingen (Wkpb) van kracht. Deze vernieuwde wet schrijft wijzigingen voor in het systeem voor het kenbaar maken van publiekrechtelijke beperkingen. Inwoners, ondernemers en overige partijen kunnen alle informatie over beperkingen en bijbehorende brondocumenten bij één partij kunnen vinden: het Kadaster.
In het oude systeem registreerden de gemeenten hun eigen gegevens terwijl andere overheden de basisregistratie van het Kadaster gebruikten. Deze twee langs elkaar werkende systemen brachten allerlei problemen met zich mee. Het was niet mogelijk om gemeentelijke brondocumenten bij het Kadaster op te vragen. En soms bleek de gemeentelijke situatie van een pand of object niet overeen te komen met de kenmerken zoals die in de basisregisters van het Kadaster zijn vastgelegd. Voorts konden overheden in het oude systeem alleen beperkingen opleggen op een kadastraal perceel, wat in veel gevallen niet aansloot op de praktijk. De vernieuwde Wkpb registreert en beheert alle publiekrechtelijke beperkingen in de Basisregistratie Kadaster publiekrechtelijke beperkingen (BRK-PB). Overheden en organisaties uit de private sector hebben zo een unieke bron waar ze alle gegevens kunnen raadplegen. En omdat beperkingen nu, behalve op een perceel, ook gelegd kunnen worden op objecten uit de de basisregistraties Adressen en Gebouwen (BAG) en Grootschalige Topografie (BGT), of via een zelf vervaardigde contour, sluit de registratie veel beter aan op de uitvoeringspraktijk.
De BRK-PB kan al benaderd worden met de BRK-API. Het bij de bron registreren en beheren van gegevens heeft hier dus zichtbare meerwaarde, zowel voor de overheid als voor de private sector , zie ook dit artikel in Binnenlands Bestuur.
2.4.4 De API voor regie op gegevens
De Wet bescherming persoonsgegevens (Wrp) en z'n opvolger, de Algemene verordening gegevensbescherming (AVG) geven ons al bijna twintig jaar recht op inzage en correctie van de gegevens die de overheid over ons verzamelt en beheert. Dit betekent dat je als burger het recht hebt om te weten welke persoonsgegevens de overheid over je heeft vastgelegd en welke gegevens de overheid heeft gebruikt en uitgewisseld voor welk doel. Uit dit onderzoek uit 2017 van Berenschot (uitgevoerd in opdracht van BZK) blijkt dat volledig digitale inzage in alle relevante persoonsgegevens die onder de AVG vallen, in het huidige gegevenslandschap niet haalbaar is.
In de beleidsbrief regie op gegevens regie op gegevens van 2019 onderstreept het kabinet nog eens het beleidsvoornemen om serieus werk te maken van regie op gegevens. Maar dan er zal er dus iets moeten gebeuren in het gegevenslandschap om dit mogelijk te maken.
Om het inzicht in de verstrekking van persoonsgegevens veel eenvoudiger te maken, is er door VNG-Realisatie een model API opgesteld, die overheden in staat kan stellen de verwerking van persoonsgegevens op een toegankelijke manier te tonen. Deze API haakt aan bij wat conform de AVG al tot stand komt: de organisatie-brede registers van verwerkingen van persoonsgegevens. Als de overheid gegevens bij de bron gaat beheren en ontsluiten met API's, wordt het gemakkelijker om bij de bron volledige inzage te geven. De overheid kan dan digitale inzage geven in een uniform gebruiksvriendelijk format, en ook de correctie van gegevens wordt eenvoudiger.
