API-standaarden: verschil tussen versies

Huidige versie van 30 apr 2024 om 15:24

Het wordt steeds belangrijker voor (applicatie)componenten om onderling goed samen te werken. Om dit mogelijk te maken kennen componenten (applicatie)services die voor andere componenten toegankelijk zijn via zogenaamde 'Application Programming Interfaces' (API's). Zo kunnen componenten op een gestructureerde manier functionaliteit van andere componenten gebruiken. Bijvoorbeeld door een API aan te bieden die voor andere componenten bruikbaar is om gegevens uit een achterliggende bronregistratie te gebruiken.

Om doelmatig en efficiënt met API's te werken is het belangrijk om de manier waarop API's worden ontwikkeld, gedocumenteerd, getest en werken te standaardiseren. Er zijn een aantal manieren om dit te realiseren. Een daarvan is het kiezen voor een bepaalde architectuurstijl. Net als in de rest van de wereld geldt ook voor de Nederlandse overheid dat de voorkeur momenteel uitgaat naar API's die werken volgens de REST-architectuurstijl. Maar dan nog geldt dat er aanvullende ontwerpkeuzes moeten worden gemaakt. Daarom is afgesproken om overheidsbrede afspraken te maken over hoe de REST-stijl wordt toegepast bij het ontwerpen van API's. Deze afspraken zijn vastgelegd in de REST-API Design Rules standaard.

Op de website developer.overheid.nl is te zien dat er steeds meer overheids-API's beschikbaar komen die allerlei soorten functionaliteit aanbieden. Op data.overheid.nl worden (ook) API-specificaties gepubliceerd waarmee open data is op te vragen. Voor gemeenten zijn met name API's interessant waarmee elders vastgelegde brongegevens toegankelijk worden gemaakt. Gebruik daarvan kan bijvoorbeeld leiden tot hogere actualiteit en betrouwbaarheid van data en het onderhouden van lokale kopieën overbodig maken.

De GEMMA Architectuurvisie beschrijft hoe standaardisatie via het gebruik van API's cruciaal is om toe te kunnen werken naar een fundamenteel betere informatievoorziening voor gemeenten. Iets dat verder wordt uitgewerkt binnen de thema-architectuur Common Ground die de architectuur uitwerkt die nodig is om de doelen van Common Ground te realiseren.

Vanuit de VNG wordt op verschillende manieren gewerkt aan de ontwikkeling van gestandaardiseerde API's:

Via het programma HaalCentraal is gewerkt aan het ontwikkelen van de HaalCentraal API's zodat gemeenten beter data kunnen opvragen uit de basisregistraties.
Het project Notificatieservices heeft een concept-standaard ontwikkeld voor het notificeren van plaatsgevonden gebeurtenissen, zoals het wijzigen van brongegevens, aan daarop geabonneerde afnemers. Deze NL GOV for CloudEvents standaard is nu in beheer bij Logius.
Voor ondersteuning van zaakgericht werken binnen gemeenten zijn API-standaarden voor zaakgericht werken ontwikkeld.

Producten
Architectuurproducten en API's

Project API referentiearchitectuur

Thema-architectuur Common Ground

Beveiligingsrichtlijnen voor API's en webservices

GEMMA standaardenlijst

API-standaardenlijst

Meer informatie
Vastgestelde standaarden op vng.nl

Overzicht gemeentelijke standaarden

Aan de slag met API-standaarden

API-specificaties (github pages)

Nederlandse API-strategie

Nederlanse API-strategie

Kennisplatform API's

Intentieovereenkomst API Strategie en Beleid

Deze pagina is het laatst bewerkt op 30 apr 2024 om 15:24.

@@ Regel 1: / Regel 1: @@
-{{Cocreatie
+Het wordt steeds belangrijker voor (applicatie)componenten om onderling goed samen te werken. Om dit mogelijk te maken kennen componenten (applicatie)services die voor andere componenten toegankelijk zijn via zogenaamde 'Application Programming Interfaces' (API's). Zo kunnen componenten op een gestructureerde manier functionaliteit van andere componenten gebruiken. Bijvoorbeeld door een API aan te bieden die voor andere componenten bruikbaar is om gegevens uit een achterliggende bronregistratie te gebruiken.
-|Cocreatiepublicatie=Cocreatie
-|GEMMAOnlinebeheerder=Beheerder Standaarden,
-}}
-[[Categorie:Berichtenstandaarden]]
-__NOTOC__
-VNG Realisatie beheert een groot deel van de gemeentelijke standaarden voor gegevens- en berichtenverkeer. Verschillende ontwikkelingen, zoals het digitaliseren van zaakgerichte processen, de Omgevingswet, nieuwe BRP, BGT en BRK, maken het vernieuwen van standaarden noodzakelijk. Op dit moment wordt daarom onder andere gewerkt aan nieuwe standaarden voor zaakgericht werken.
-=== Nieuwe standaarden voor zaakgericht werken ===
+Om doelmatig en efficiënt met API's te werken is het belangrijk om de manier waarop API's worden ontwikkeld, gedocumenteerd, getest en werken te standaardiseren. Er zijn een aantal manieren om dit te realiseren. Een daarvan is het kiezen voor een bepaalde architectuurstijl. Net als in de rest van de wereld geldt ook voor de Nederlandse overheid dat de voorkeur momenteel uitgaat naar API's die werken volgens de [https://en.wikipedia.org/wiki/Representational_state_transfer REST-architectuurstijl]. Maar dan nog geldt dat er aanvullende ontwerpkeuzes moeten worden gemaakt. Daarom is afgesproken om overheidsbrede afspraken te maken over hoe de REST-stijl wordt toegepast bij het ontwerpen van API's. Deze afspraken zijn vastgelegd in de [https://www.forumstandaardisatie.nl/open-standaarden/rest-api-design-rules REST-API Design Rules] standaard.
-Volgens een agile proces wordt een [https://ref.tst.vng.cloud/ nieuwe generatie standaarden voor zaakgericht werken] ontwikkeld. Op basis van [https://nl.wikipedia.org/wiki/User_story user stories] worden RESTful API’s gedefinieerd die gewenste functionaliteit bieden. Tegelijkertijd ontwikkelen we referentie-implementaties, die de werking tonen en dienen als voorbeeld voor ontwikkelaars die de standaard willen implementeren.
+Op de website [https://developer.overheid.nl developer.overheid.nl] is te zien dat er steeds meer overheids-API's beschikbaar komen die allerlei soorten functionaliteit aanbieden. Op [https://data.overheid.nl/ data.overheid.nl] worden (ook) API-specificaties gepubliceerd waarmee open data is op te vragen. Voor gemeenten zijn met name API's interessant waarmee elders vastgelegde brongegevens toegankelijk worden gemaakt. Gebruik daarvan kan bijvoorbeeld leiden tot hogere actualiteit en betrouwbaarheid van data en het onderhouden van lokale kopieën overbodig maken.
-=== Hoe komen we samen tot API-standaarden===
+De [[Architectuurvisie|GEMMA Architectuurvisie]] beschrijft hoe standaardisatie via het gebruik van API's cruciaal is om toe te kunnen werken naar een fundamenteel betere informatievoorziening voor gemeenten. Iets dat verder wordt uitgewerkt binnen de [[thema-architectuur Common Ground]] die de architectuur uitwerkt die nodig is om de doelen van Common Ground te realiseren.
-Standaarden kunnen we alleen samen maken. We waarderen alle suggesties, zijn blij met feedback en verwelkomen verbeteringen in dit project. Brede samenwerking leidt tot de beste 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, t.w.:
+Vanuit de VNG wordt op verschillende manieren gewerkt aan de ontwikkeling van gestandaardiseerde API's:
-*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 tesamen zullen de openbare consultatie vormen/vervangen. 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.
+* Via het programma HaalCentraal is gewerkt aan het ontwikkelen van de [https://vng-realisatie.github.io/Haal-Centraal/ HaalCentraal API's] zodat gemeenten beter data kunnen opvragen uit de basisregistraties.
+* Het project Notificatieservices heeft een concept-standaard ontwikkeld voor het notificeren van plaatsgevonden gebeurtenissen, zoals het wijzigen van brongegevens, aan daarop geabonneerde afnemers. Deze [https://logius.nl/domeinen/gegevensuitwisseling/nl-gov-profile-cloudevents NL GOV for CloudEvents standaard] is nu in beheer bij Logius.
+* Voor ondersteuning van zaakgericht werken binnen gemeenten zijn [https://vng.nl/projecten/zaakgericht-werken-api API-standaarden voor zaakgericht werken] ontwikkeld.
-<big>'''Problemen, suggesties en vragen'''</big>
+{{Landingspagina
+|titel1  = Producten
+|inhoud1 =
+Architectuurproducten en API's
+* [[Project API referentiearchitectuur]]
+* [[Thema-architectuur Common Ground]]
+* [[Beveiligingsrichtlijnen voor API's en webservices]]
-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 [https://github.com/VNG-Realisatie/gemma-zaken/issues issue worden gemaakt]. Op de supportpagina’s van GitHub staat [https://help.github.com/en/articles/creating-an-issue uitleg over het maken van issues].
+GEMMA standaardenlijst
+* [[GEMMA API-standaardenlijst|API-standaardenlijst]]
+|titel2  = Meer informatie
+|inhoud2 =
+Vastgestelde standaarden op vng.nl
+* [https://vng.nl/artikelen/overzicht-gemeentelijke-standaarden Overzicht gemeentelijke standaarden]
-Documentatie en code
+Aan de slag met API-standaarden
+* [https://vng-realisatie.github.io/Standaarden/API-standaarden API-specificaties (github pages)]
-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/).
+Nederlandse API-strategie
+* [https://docs.geostandaarden.nl/api/API-Strategie/ Nederlanse API-strategie]
+* [https://www.geonovum.nl/themas/kennisplatform-apis Kennisplatform API's]
+* [https://www.geonovum.nl/themas/kennisplatform-apis/intentie-overeenkomst Intentieovereenkomst API Strategie en Beleid]
-<big>'''1. Maak je wijzigingen'''</big>
-Dit project hanteert het [https://www.endoflineblog.com/oneflow-a-git-branching-model-and-workflow 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.
+|hoogte = 350px
+}}
-<big>'''2. Pull Request'''</big>
+{{Publicatie
+|Paginastatus=publiceren
-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.
+|Redactiestatus=Actueel
+|Wikibeheerder=GEMMA Beheer
-<big>'''3. Verbeteren'''</big>
+}}
+[[Category:Standaarden paginas]]
-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.
-<big>'''Agile Scrum'''</big>
-Het team wat aan de ZGW API’s werkt doet dit volgens de agile scrum methodiek. Iedere sprint duurt vier weken. Gemeenten leveren user stories rond zaakgericht werken, welke vervolgens worden vertaald naar wat nodig is in de RESTful API specificatie.
-'''Scrum boards'''
-Er worden vier scrum boards gebruikt om de flow naar resultaat in elke sprint te faciliteren.
-*[https://github.com/VNG-Realisatie/gemma-zaken/projects/1 Scrum ZGW Voorbereiding] Nieuwe user stories en issues komen hier op de backlog. Wanneer zij worden geprioriteerd komen ze in de flow om ze ‘ready te maken’ zodat ze opgepakt kunnen worden in de volgende sprint.
-*[https://github.com/VNG-Realisatie/gemma-zaken/projects/3 Scrum ZGW Realisatie Sprint x] Vanuit de kolom “Ready for Sprint” worden tijdens de maandelijkse sprint planning userstories opgepakt die uitgevoerd gaan worden. Deze komen dan in de eerste kolom van het scrum board gericht op realisatie van de API specificatie.
-*[https://github.com/VNG-Realisatie/gemma-zaken/projects/4 Scrum ZGW Gereed Archief] Op dit board is terug te vinden welke user story gereed was in welke sprint.
-*[https://github.com/VNG-Realisatie/gemma-zaken/projects/2 Organisatie & Impediments] Op dit board bewaakt het team de voortgang van niet-inhoudelijke actiepunten en blokkades.
-<big>'''Review'''</big>
-Zowel het board [https://github.com/VNG-Realisatie/gemma-zaken/projects/1 Scrum ZGW Voorbereiding] als [https://github.com/VNG-Realisatie/gemma-zaken/projects/3 Scrum ZGW Realisatie] bevat een kolom voor review. Tijdens de voorbereiding worden user stories klaargemaakt om in een volgende sprint uitgevoerd te worden. Daar hoort een review bij: voldoet de user story aan de Definition of Ready? Na de realisatie vindt opnieuw een review plaats, van iedere Pull Request waarmee een wijziging of toevoeging op de standaard wordt gedaan.
-Reviews worden vaak aan specifieke personen gevraagd, maar iedereen kan een review uitvoeren. Wanneer de beoordeling binnen je competenties valt, geef de review dan prioriteit boven eventuele andere bijdragen zodat iedereen zo snel mogelijk verder kan.
-=== Status nieuwe 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 dit 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.
-<!-- Page revision date: 1554117077 -->

API-standaarden: verschil tussen versies

Huidige versie van 30 apr 2024 om 15:24

Nieuws

Contact[bewerken]

Bezoekadres[bewerken]

Postadres[bewerken]