API-standaarden: verschil tussen versies

Regel 2: Regel 2:
 
|Cocreatiepublicatie=Cocreatie
 
|Cocreatiepublicatie=Cocreatie
 
|Redactiestatus=Actueel
 
|Redactiestatus=Actueel
|GEMMAOnlinebeheerder=Beheerder Standaarden
+
|GEMMAOnlinebeheerder=GEMMA Beheer
 
}}
 
}}
[[Categorie:Berichtenstandaarden]]  
+
[[Category:Standaarden]]
__NOTOC__
+
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.
==Standaard API-specificaties==
 
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.
 
  
Standaarden kunnen volgens [https://vng.nl/sites/default/files/brieven/2018/attachments/08_notitie_proces_standaardverklaring_versie_cie_i_en_bestuur.pdf drie niveaus van verbindendheid] worden vastgesteld:
+
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.
# Advies ('Aanbevolen')
 
#* Mate van verbindendheid: vrijblijvend en geen formele status.
 
#* Proces vaststelling: vaststellen door directie VNG
 
#* Voorbeeld: klantreizen, modelverordeningen
 
# Standaardverklaring ('Pas toe of leg uit')
 
#* Mate van verbindendheid: niet vrijblijvend, ‘pas toe of leg uit’-principe [https://www.forumstandaardisatie.nl/node/229 naar voorbeeld Forum Standaardisatie].
 
#* Proces vaststelling: tenminste op advies van het College van Dienstverleningszaken door bestuur VNG, ledenraadpleging facultatief, monitoring toepassing door VNG (bijvoorbeeld via Waarstaatjegemeente.nl) en lokaal via reguliere P&C cyclus door gemeenteraad.
 
#* Voorbeeld: GIBIT
 
# Verbindend verklaren ('Verplicht')
 
#* Mate van verbindendheid: verplichtend voor leden
 
#* Proces: vaststelling op advies College van Dienstverleningszaken door bestuur VNG metledenraadpleging
 
#* Voorbeeld: Aansluiting bij Informatiebeveiligingsdienst (via BALV)
 
<br>
 
  
{| class="wikitable"
+
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.  
! API-standaard !! In beheer bij !! In ontwikkeling <small>- 1.0-versie verwacht in</small> !! In gebruik (versie ≥ 1.0 ) <small>vanaf datum</small> !! Mate van verbindendheid
 
|-
 
|- bgcolor="#f4c8d5"
 
|colspan="5" |''Onderdeel van API-standaarden in domein Dienstverlening (Zaakgericht werken)''
 
|-
 
|[https://zaken-api.vng.cloud/ Zaken API] || VNG Realisatie || || 27-11-2019 || pas toe of leg uit
 
|-
 
|[https://catalogi-api.vng.cloud/ Catalogi API] || VNG Realisatie || || 27-11-2019 || pas toe of leg uit
 
|-
 
|[https://documenten-api.vng.cloud/ Documenten API] || VNG Realisatie || || 27-11-2019 || pas toe of leg uit
 
|-
 
|[https://besluiten-api.vng.cloud/ Besluiten API] || VNG Realisatie || || 27-11-2019 || pas toe of leg uit
 
|-
 
|[https://autorisaties-api.vng.cloud/ Autorisaties API] || VNG Realisatie || || 27-11-2019 || pas toe of leg uit
 
|-
 
|[https://notificaties-api.vng.cloud/ Notificaties API] || VNG Realisatie || || 27-11-2019 || pas toe of leg uit
 
|-
 
|[https://github.com/maykinmedia/objects-api/ Objecten API]<br>[https://github.com/maykinmedia/objecttypes-api Objecttypen API] || OpenZaak Community || || 13-01-2021 || pas toe of leg uit
 
|-
 
|- bgcolor="#c4e5d6"
 
|colspan="5" | ''Onderdeel van Haal Centraal''
 
|-
 
| bgcolor="#effafe" | [https://github.com/VNG-Realisatie/Haal-Centraal-BAG-bevragen/ BAG Bevragen API] || Kadaster || || 13-08-2020 || pas toe of leg uit
 
|-
 
| bgcolor="#effafe" | [https://github.com/VNG-Realisatie/Haal-Centraal-BRK-bevragen/ BRK Bevragen API] ||Kadaster || || 03-06-2020 || pas toe of leg uit
 
|-
 
| bgcolor="#effafe" | [https://github.com/BRP-API/Haal-Centraal-BRP-bevragen/ BRP Bevragen API] || RvIG || || 01-10-2020 || pas toe of leg uit
 
|-
 
| bgcolor="#effafe" | [https://github.com/VNG-Realisatie/Haal-Centraal-WOZ-bevragen/ WOZ Bevragen API] || Waarderingskamer || || 16-12-2021 || pas toe of leg uit
 
|-
 
|- bgcolor="#f4c8d5"
 
|colspan="5" |''Onderdeel van API-standaarden in Fysiek domein''
 
|-
 
|[https://github.com/VNG-Realisatie/Regels-bij-activiteiten Regels bij activiteiten API] || VNG Realisatie || || 01-07-2021 || pas toe of leg uit
 
|-
 
|}
 
  
==API-specificaties in ontwikkeling==
+
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.  
Een compleet overzicht van alle in ontwikkeling zijnde API-specificaties is te vinden op de [[Ontwikkelagenda API-standaarden|ontwikkelagenda API-standaarden]].
 
  
Heb je zelf een idee voor een standaard? Volg dan het [[Standaardisatieproces|standaardisatieproces]], welke de leidraad geeft van te volgen stappen om van ‘idee’ tot ‘vastgestelde VNG uitwisselstandaarden’ te komen.
+
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 [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.
 +
 
 +
{{Landingspagina
 +
|titel1  = Producten
 +
|inhoud1 =
 +
* [[Overzicht_vastgestelde_standaarden | Overzicht vastgestelde API-standaarden]]
 +
* [[Ontwikkelagenda_API-standaarden | API-standaarden ontwikkelagenda]]
 +
* [[Standaardisatieleidraad | API-standaardisatieleidraad]]
 +
* [[Beoordelingsaspecten_ontwikkeling_standaard | API-beoordelingsaspecten]]
 +
* [[Beheer_API-specificatie | API-beheer]]
 +
* [[Communities | API-ontwikkeling communities]]
 +
* [[API_kwaliteitscriteria | API-kwaliteitscriteria]]
 +
 
 +
|titel2  = Meer informatie
 +
|inhoud2 =
 +
* [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]
 +
|hoogte = 350px
 +
}}

Versie van 30 mrt 2023 01:02


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.



Deze pagina is het laatst bewerkt op 30 mrt 2023 om 01:02.