API-standaarden


VNG Realisatie beheert een groot deel van de gemeentelijke standaarden voor gegevens- en berichtenverkeer. Ontwikkelingen, als het digitaliseren van zaakgerichte processen, de Omgevingswet en de nieuwe BRP, BGT en BRK maken het vernieuwen van standaarden noodzakelijk. Dit heeft in 2019 geleid tot een release van de 1.0-versie van de API-standaarden voor Zaakgericht Werken. Maar gemeenten, ketenpartners en de VNG werken aan meer API-standaarden, onder andere voor het bevragen van een aantal basisregistraties.

Deze pagina geeft overzicht van API-standaarden die geschikt zijn voor gebruik in productiesystemen, maar toont ook API-standaarden waarvoor binnenkort een 1.0-release wordt verwacht. Bovendien wordt een eventuele verbindendverklaring vermeld.

Overzicht API-standaarden voor gemeenten

API-standaard In beheer bij In ontwikkeling - 1.0-versie verwacht in In gebruik (versie ≥ 1.0 ) vanaf datum Mate van verbindendheid
Onderdeel van API-standaarden voor Zaakgericht Werken
Zaken API VNG Realisatie 27-11-2019 nader te bepalen
Catalogi API VNG Realisatie 27-11-2019 nader te bepalen
Documenten API VNG Realisatie 27-11-2019 nader te bepalen
Besluiten API VNG Realisatie 27-11-2019 nader te bepalen
Autorisaties API VNG Realisatie 27-11-2019 nader te bepalen
Notificaties API VNG Realisatie 27-11-2019 nader te bepalen
Klanten API Q3 2020 nader te bepalen
Contactmomenten API Q3 2020 nader te bepalen
Verzoeken API Q3 2020 nader te bepalen
Onderdeel van Haal Centraal
BAG Bevragen API Q3 2020 nader te bepalen
BAG Update API Q4 2020 nader te bepalen
BRK Bevragen API 3-6-2020 nader te bepalen
BRK Update API Q4 2020 nader te bepalen
BRK Gebeurtenissen API Q4 2020 nader te bepalen
BRP Bevragen API Q4 2020 nader te bepalen
BRP Update API nog niet bekend nader te bepalen
HR Bevragen API nog niet bekend nader te bepalen
BGT Bevragen API nog niet bekend nader te bepalen
WOZ Bevragen API nog niet bekend nader te bepalen
Overige API-standaarden
Open Raadsinformatie API 2020 nader te bepalen

In laatste drie kolommen in de tabel hierboven corresponderen met drie statussen:

  1. 'In ontwikkeling' (meest recente versie < 1.0)
  2. 'In gebruik' (meest recente versie ≥ 1.0)
  3. 'Verbindend verklaard' (aangegeven middels mate van verbindendheid)

1. In ontwikkeling

API-standaarden met de status 'in ontwikkeling' kunnen gebruikt worden door gemeenten en leveranciers, maar toepassing in productiesystemen wordt niet aanbevolen. Veranderingen in specificaties die ervoor zorgen dat voorgaande versies of afhankelijke componenten niet langer werken ('breaking changes') kunnen onbeperkt en onaangekondigd worden doorgevoerd. De ontwikkelingsfase eindigt met het uitbrengen van een release candidate - een versie van de API die de voorgenomen productiespecificaties omvat waarop belanghebbende gedurende een bepaalde periode kunnen reageren.

2. In gebruik

Als een API-standaard de release cadidatefase succesvol heeft doorlopen, wordt een productieversie uitgebracht. Een API met een versienummer van 1.0 of hoger krijgt de status 'in gebruik', en is geschikt voor gebruik in productiesystemen. API-standaarden met de status 'in gebruik' kunnen door gemeenten en leveranciers in productiesystemen worden geïmplementeerd. De in de Gemeentelijke ICT-kwaliteitsnormen bij de GIBIT benoemde verplichting tot implementatie van API-standaarden geldt vanaf het moment dat een API-standaard de status 'In gebruik' heeft bereikt.

Veranderingen in specificaties die ervoor zorgen dat voorgaande versies of afhankelijke componenten niet langer werken ('breaking changes') kunnen maximaal twee keer per jaar gedurende vastgestelde releasemomenten worden doorgevoerd. Deze resulteren altijd in een nieuwe 'major release'. VNG Realisatie ondersteunt voor iedere API-standaard de meest recent uitgebrachte major release en (voor zover van toepassing) de voorafgaand uitgebrachte major release. Minor releases, die geen breaking changes omvatten kunnen onbeperkt en op ieder moment worden uitgebracht. Meer details over het releasebeleid is te vinden op GitHub-pagina over versiebeheer en releasemangement. De hier beschreven uitgangspunten gelden alleen voor API-standaarden die door VNG Realisatie worden beheerd.

3. Verbindend verklaard

Een verbindend verklaarde API-standaard is na een advies van het College van Dienstverleningszaken door het VNG-bestuur of de Algemene Ledenvergadering van de VNG als standaard vastgesteld. Een vaststelling kan verschillende gradaties van verbindendheid tot gevolg hebben: van 'aanbevolen deze standaard te gebruiken' tot 'verplicht deze standaard toe te passen'. In de tabel wordt per vastgestelde API-standaard aangegeven welke mate van verbindendheid geldt.

Een een API-standaard met de status 'in ontwikkeling' zal op een gegevens moment vrijwel altijd de status 'in gebruik' bereiken. Deze statussen zijn opeenvolgend. Voor een verbindendverklaring geldt iets anders: die is aanvullend is bij de status 'in gebruik'. Een verbindendverklaring bepaalt alléén de mate waarin gemeenten verplicht zijn een (API-)standaard toe te passen, en beïnvloedt dus niet de geschiktheid van die API-standaard voor gebruik in productiesystemen of het releasebeleid van de standaard. De relatie tussen ontwikkeling en vaststelling van API-standaarden wordt in het diagram hieronder geïllustreerd.

Illustratie bij ontwikkeling en vaststelling van API-standaarden

Specifieke API-standaarden

API-standaarden voor zaakgericht werken

Van de APIs voor zaakgericht werken is eind 2019 een eerste productieversie (versie 1.0.0) gepresenteerd. Meer informatie over deze standaarden is te vinden op de website van VNG Realisatie. Voor ontwikkelaars is meer documentatie beschikbaar via de GitHub-repository.

Haal Centraal bevragen basisregistraties

Onder de noemer 'Haal Centraal' wordt gewerkt aan API-definitities die het mogelijk maken om de BRP, BRK en BAG te bevragen. Meer informatie is te vinden op de Github-repository's voor BRP bevragen, BRK bevragen en BAG bevragen.

Hoe komen we samen tot API-standaarden?

Voorheen werd er toegewerkt naar één openbare consultatie waarmee een standaard eenmalig werd getoetst bij stakeholders. Bij de nieuwe werkwijze is er sprake van een voortdurende afstemming met partijen waarbij meerdere instrumenten worden ingezet, te weten:

  • Repositories op Github: te allen tijde kunnen partijen de stand van zaken raadplegen en de planning raadplegen. Ook kunnen zij bugs inschieten en wensen aanmelden in de vorm van user stories.
  • Referentiecomponenten en API testvoorziening in de cloud waartegen getest kan worden.
  • Elke vier weken wordt er een publieke Sprint-demo georganiseerd waar de gerealiseerde user stories worden gedemonstreerd. Bezoekers kunnen vragen stellen en direct feedback geven op de resultaten.
  • API-labs, eveneens openbaar, geven developers van gemeenten en leveranciers de kans om met ondersteuning van het ZGW team te experimenteren met de API’s. Ook hier kunnen uiteraard bugs en nieuwe wensen gemeld worden.
  • Presentaties op de Leveranciersdag van VNG-Realisatie

Deze instrumenten tezamen zijn onderdeel van de openbare consultatie. Er zal dus sprake zijn van een voortdurende consultatie van de stakeholders, waarmee ook de kans ontstaat om de standaard voortdurend te verbeteren op aangeven van de gebruikers.

‘Issues’ en ‘Pull Requests’ zijn dus meer dan welkom.

Problemen, suggesties en vragen

Het is niet nodig om software of documentatie te schrijven om toch bij te dragen. De ontwikkeling is ook gebaat bij gerapporteerde problemen, suggesties voor wijzigingen en vragen over dingen die (nog) onduidelijk zijn. Om dit te doen kan een issue worden gemaakt. Op de supportpagina’s van GitHub staat uitleg over het maken van issues.

Documentatie en code

Maak om bij te dragen aan de documentatie of software van de ZGW API’s een zogenaamde Pull Request. Lees alles over hoe git (en GitHub) werkt in deze introductie over git flow](https://guides.github.com/introduction/flow/).

1. Maak je wijzigingen

Dit project hanteert het OneFlow branching model. Maak je wijzigingen op een nieuwe ‘feature branch’ met de naam feature/naam-die-bijdrage-beschrijft. Zorg voor heldere beschrijvingen voor iedere commit, zodat degenen die de bijdrage moeten beoordelen een goed beeld hebben van wat de bedoeling is.

2. Pull Request

Wanneer de bijdrage compleet op de nieuwe feature branch staat kun je een Pull Request maken. Dit is, zoals de naam zegt, een verzoek aan de eigenaren van de repository om de branch met wijzigingen op te halen en in het project te voegen. Verzoek daarbij is om elke Pull Request te voorzien van een duidelijke beschrijving en eventuele issue nummers die met behulp van de Pull Request worden opgelost.

3. Verbeteren

Alle bijdragen worden beoordeeld in een review proces. Je kunt zelf ook specifiek aan een teamlid vragen om een review.

Het kan zijn dat een Pull Request direct kan worden ingevoegd. Vaak is het echter nodig om nog het e.e.a. te verbeteren aan de Pull Request voordat deze in het project kan worden ingevoegd. Feedback op de Pull Request kan komen van de eigenaren van de standaard, van andere belanghebbenden of van geautomatiseerde tests.

Wanneer de gewijzigde documentatie en code door de menselijke review en geautomatiseerde test komt, worden de wijzigingen van de Pull Request in het project gevoegd.

Status vernieuwde informatiemodellen

De informatiemodellen RSGB3, RGBZ2 en ImZTC2.02 zijn goedgekeurd. Toch hebben de nieuwe versies van deze standaarden de status ‘in ontwikkeling’. Zij krijgen de status ‘in gebruik’ nadat ze zijn geïmplementeerd in één of meer standaarden.

Wat betekent de ontwikkeling van API-standaarden voor de bestaande StUF-standaarden?

De ontwikkeling van StUF 03.02 en de daarmee samenhangende sectormodellen StUF BG 03.20 en StUF ZKN 03.20 is stopgezet. VNG Realisatie blijft support leveren bij de huidige generatie StUF-standaarden. Dat betekent dat we bugs, fouten en problemen herstellen.