2.1 Samenvatting
De platformeconomie biedt nieuwe kansen voor de digitale overheid. Om deze kansen te benutten en tegelijkertijd de dienstverlening van de digitale overheid te verbeteren vindt er transitie plaats in het gegevenslandschap. Initiatieven zoals Common Ground, Toekomst BRP en het Digitaal Stelsel Omgevingswet (DSO) willen de digitale overheid efficiënter, slimmer, veiliger en beter beheersbaar maken door applicaties beter te scheiden van de gegevens en de gegevens alleen bij de bron te beheren. Hierdoor hoeven gegevens niet meer op grote schaal gedupliceerd en gesynchroniseerd te worden. In deze ambitie spelen API’s als ondersteunende technologie een belangrijke rol.
De overheid gebruikt data voor het oplossen van maatschappelijke vraagstukken en opgaven zoals in wonen, stikstof, de energietransitie, armoede, de bestrijding van criminaliteit en ondermijning, 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.
Nagenoeg alle organisaties binnen de overheid zijn de omslag van traditionele IT naar een API-ecosysteem aan het maken. Dit hoofdstuk biedt een kader aan waarbinnen de overheid zich kan committeren bij ontwikkeling en te realiseren beleid rondom API’s. Het hoofdstuk sluit af met een Intentieverklaring van organisaties uit de publieke sector die dit commitment willen geven. De uitnodiging is open aan alle organisaties uit de publieke sector om ook te ondertekenen.
2.2 Visie
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.2.2 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 al afspraken en standaarden voor API’s op het gebied van authenticatie, autorisatie, logging en andere onderwerpen die data beter en op een uniforme manier toegankelijk en bruikbaar maken. 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.3 API first Strategie
De API first strategie past binnen de huidige beleidsdoelen en de omgeving van de publieke sector. Eerst leggen we uit wat "API first" inhoud daarna hoe je daarmee je omgeving bediend en voor welke beleidsdoelen "API first" relevant is. Als laatste zetten we de strategie om in 4 acties die in het beleid van een "API first" organisatie opgenomen zouden moeten worden.
2.3.1 API first
Iedere organisatie zou voor ontsluiting van data en functionaliteit altijd "API first" moeten werken:
- Altijd is er een goed gedocumenteerde machine interface die aan de omgeving ter beschikking gesteld kan worden.
- Voor de ontsluiting die je zelf direct realiseert (bijvoorbeeld een website) maak je gebruik van diezelfde interface. Het geeft je omgeving de mogelijkheid om daar waar er voor hen geen geschikte ontsluiting bestaat, deze 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".
- Maak gebruik van API technieken die breed in de markt ondersteund worden. Dat zorgt ervoor dat benodigde kennis en middelen voor het toepassen eenvoudig verkrijgbaar zijn. Zorg dus voor actuele kennis binnen je organisatie over wat er in de markt speelt, en deel deze kennis met andere organisaties. Op moment van schrijven zijn REST API's op basis van HTTP en JSON bijvoorbeeld breed ondersteund, maar dat kan in de toekomst veranderen.
- API first is niet alleen een voorwaarde voor moderne IT systemen, het toepassen ervan is ook een middel voor modernisering, zoals Common ground en PSD2 laten zien (zie sectie bedien de omgeving).
2.3.2 API first voor de 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.
2.3.2.1 Burgers
Zo herkent iedere burger hoe eenvoudig verschillende platforms uit de platform economie (zoals Google, Amazon, Linkedin en Meta) eenvoudig elkaars functionaliteit integreren. Denk aan de store in store concepten bij grote online retailers en knoppen om informatie te delen op je favoriete sociale medium.
2.3.2.2 Bedrijven
Het bedrijfsleven weet hoe via de "payment service directive 2" (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 salarisadministratie door API's met elkaar te integreren zijn.
De grootste kennis in de markt van (potentiële) softwareleveranciers in de publieke sector voor het verbinden van IT systemen ligt mede om bovengenoemde redenen bij API's.
2.3.2.3 Publieke sector
In de publieke sector zelf zijn API's in sommige onderdelen 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.
2.3.2.4 Bedien de omgeving
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 aanbiedt.
Je moet ze dus niet dwingen om één manier te gebruiken. Tegenwoordig zijn er vele manieren om data & functionaliteit te ontsluiten:
- websites,
- mobiele Apps,
- computer applicaties,
- IoT devices,
- fysieke loketten, en
- brievenpost.
Achter al deze ontsluitingsmanieren zit een IT systeem. Het is in de huidige digitale samenleving niet reëel om al deze manieren volledig zelf in de hand te hebben. Door direct toegang te geven tot data en functionaliteit door een API bied je de mogelijkheid om deze via verschillende kanalen aan te bieden. Je kan voor ieder kanaal afwegen of je dat als organisatie zelf aanbiedt of dit aan een andere partij overlaat.
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. 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 transitiemechanisme. API's worden gebruikt om in stappen over te gaan naar een nieuwe manier van werken waarbij API's het ontkoppelpunt vormen.
2.3.3 API first voor beleidsdoelen
Om de beleidsdoelen van de overheid te halen is doorontwikkeling van de digitale overheid van groot belang. API's 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.
- In nieuwe wetgeving wordt de digitale overheid steeds belangrijker. De Wet hergebruik overheidsinformatie (Who) beoogt het hergebruik van overheidsinformatie mogelijk te maken, voor doelstelling anders dan het oorspronkelijke doel waarmee de informatie aangemaakt is. Anders dan bij de WOB moet informatie machine-leesbaar aangeboden worden, bij voorkeur in open formaten met open standaarden. De Wet modernisering elektronisch bestuurlijk verkeer is in behandeling. Het gaat om een wijziging van Algemene wet bestuursrecht (Awb) waarbij bestuurorganen verplicht digitale kanalen moeten bieden voor digitale berichten. Het gebruik van API's kan dus helpen invulling te geven aan deze wettelijke plichten.
- 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. Onderstaande acties verdienen verankering in het beleid van de organisatie wanneer je API first wilt werken.
2.3.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 hoe informatie door open API-standaarden wordt uitgewisseld. Samenwerking met de markt op basis van open standaarden is wenselijk. Samenwerking op basis van eigen oplossingen van leveranciers 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 gebeurt. Met name als die bij de grote platforms terecht komt. De samenleving verwacht van organisaties in de publieke sector dat die zorgvuldig met hun gegevens omgaan. Het gebruik van niet-open standaarden voor gegevensuitwisseling past daar niet bij.
2.3.5 Actie 2: Gebruik API's bij (ver)bouw van IT-systemen
Gebruik de standaarden bij inkoop voor nieuwbouw en verbouw van IT-systemen. Dit begint bij het volgen van de lijsten met verplichte en veelgebruikte standaarden van het Forum Standaardisatie. Daar zijn de verplichte en veel gebruikte API-standaarden te vinden. Het toepassen van standaarden is echter het begin, pas ze toe binnen een modulair opgebouwde architectuur volgens de NORA. Maar denk vooral ook na over het ontwerp van je API's. Dit moet afgestemd zijn op de behoefte van de afnemers van de API. Zorg ervoor dat je de omgeving van je organisatie en de onderdelen van je eigen organisatie zo goed mogelijk bedient. Het gebruik van API's maakt het mogelijk verschillende onderdelen van een IT-systeem zo veel mogelijk te ontkoppelen (onafhankelijk van elkaar te maken). Dit zorg ervoor dat het systeem in de toekomst met minimale inspanning op nieuwe eisen en uitdagingen is aan te passen. Volg niet alleen bij standaarden maar ook bij het ontwerp de kennis van de markt. Brede marktondersteuning zorgt ervoor dat er veel te kiezen valt als je ondersteuning nodig hebt (of het nu gaat om vinden van geschikt personeel of aanschaf van software). Meer keuze in de markt leidt tot lagere kosten.
2.3.6 Actie 3: Deel Kennis over het 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 om ontwerpkeuzes binnen API's, voor de IT-architectuur waarbinnen API's gebruikt worden en over de vindbaarheid van API's. We streven ernaar deze binnen bestaande structuren en afspraken zoals over het toepassen van de lijst met verplichte standaarden van het Forum Standaardisatie en de NORA vast te stellen.
2.3.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, de 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 de grenzen van openbaarheid) centraal en publiekelijk vindbaar zijn, dus niet alleen via de kanalen van de aanbiedende organisatie maar ook vanuit landelijke portalen/catalogi.
2.4 Praktijkvoorbeelden
2.4.1 De BRP API van RvIG (voorheen 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 die kopiedatabase bevraagd in processen waarvoor persoonsgegevens nodig zijn. Binnen het programma Toekomst BRP experimenteert de Rijksdienst voor Identiteitsgegevens (RvIG) met een API waarmee gemeenten in hun werkprocessen direct de Basisregistratie Personen (BRP) kunnen bevragen. De API is gerealiseerd in samenwerking met gemeenten en gebaseerd op de informatiebehoefte van gemeenten, provincies en waterschappen. De API biedt niet alleen persoonsgegevens uit de BRP, maar ook informatieproducten zoals leeftijd, aanschrijfwijze, aanhef, verwijzing naar een persoon in de tekst van een brief, adressering (passend voor brief en vensterenvelop), en historische bewoning van een adres. Hiervoor is een wetwijziging nodig: het Experimentbesluit Dataminimalisatie. Gemeenten en andere afnemers van de BRP met een autorisatiebesluit van RvIG mogen zonder extra kosten deelnemen aan het experiment en de BRP API gebruiken.
Over de voordelen van de BRP API heeft Haal Centraal een heldere video gemaakt. Op de developer portal van de BRP API vind je hoe je kunt aansluiten en aan welke voorwaarden moet worden voldaan. Als het experiment slaagt, wordt gewerkt aan structurele wetgeving die dataminimalisatie door vraaggestuurde productontwikkeling met API's mogelijk maakt.
2.4.2 De API's voor verstrekken van gegevens aan burgers (Vorderingenoverzicht Rijk)
Het verzamelen van gegevens over actuele betalingsverplichtingen is voor burgers die in schuldhulpverlening terecht komen een grote drempel. Ook in andere situaties willen burgers graag toegang tot gegevens die over hen zijn vastgelegd, bijvoorbeeld om snel te checken of je geen rekening gemist hebt. Het opvragen van die gegevens werkt overal anders en kost veel tijd en middelen. Het Vorderingenoverzicht Rijk verlaagt die drempels, door middel van standaardiseren en automatiseren, zodat problemen met betalingen en schulden sneller kunnen worden opgelost of worden voorkomen. Het Vorderingenoverzicht Rijk maakt dit mogelijk met API-first ontwerp dat invulling geeft aan het API-contactoppervlak G2C uit de Nederlandse API Strategie: API's voor burgers maken het mogelijk dat burgers daadwerkelijk zelf digitaal zaken doen met de overheid. Met de API's van het Vorderingenoverzicht Rijk kan een burger alle informatie over zijn financiële verplichtingen aan overheidsorganisaties opvragen bij de bronnen, tonen in één overzicht, en op basis daarvan de gewenste acties ondernemen.
2.4.3 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.4 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.5 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.
2.5 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.
