API-standaarden: verschil tussen versies

Geen bewerkingssamenvatting
Geen bewerkingssamenvatting
 
(69 tussenliggende versies door 4 gebruikers niet weergegeven)
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
 
}}
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.
[[Categorie:Berichtenstandaarden]]  
 
__NOTOC__
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.
==1 Vernieuwing StUF 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.
 
Vanuit de VNG wordt op verschillende manieren gewerkt aan de ontwikkeling van gestandaardiseerde API's:


Verschillende ontwikkelingen maken het vernieuwen van standaarden noodzakelijk om invulling te (blijven) geven aan de behoefte en wensen van gemeenten. Ontwikkelingen zijn het digitaliseren van zaakgerichte processen (Digitale Agenda 2020), de omgevingswet, nieuwe BRP, BGT en BRK.
* 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.  
KING beheert een groot deel van de gemeentelijke standaarden voor gegevens en berichtenverkeer. In de Regiegroep Gegevens en Berichtstandaarden zijn reeds afspraken gemaakt over de doorontwikkeling en  vernieuwing van deze standaarden. De vernieuwing wordt vormgegeven in twee sporen namelijk het ‘doorontwikkeling’  spoor en het ‘ontdekken’ spoor. Beide sporen zijn gebaseerd op de vernieuwde informatiemodellen RSGB3, RGBZ2 en ImZTC2.2en hebben daarmee dezelfde semantische basis. <br />
* 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.


=== 1.1 Doorontwikkelingspoor ===
{{Landingspagina
|titel1  = Producten
|inhoud1 =  
Architectuurproducten en API's
* [[Project API referentiearchitectuur]]
* [[Thema-architectuur Common Ground]]
* [[Beveiligingsrichtlijnen voor API's en webservices]]


Het doorontwikkelingspoor  geeft invulling aan de behoefte om op korte termijn nieuwe scherpe koppelvlakken te kunnen realiseren die gebruik maken van de vernieuwde informatiemodellen zodat aangesloten kan worden bij de vernieuwing van de basisregistraties. Om een snelle ontwikkeling, vaststelling en implementatie van koppelvlakstandaarden mogelijk te maken is de huidige StUF familie met bijbehorend governancemodel het uitgangspunt voor de doorontwikkeling. Er worden belangrijke wijzigingen doorgevoerd om de complexiteit te reduceren, code-generatie op basis van schema’s mogelijk te maken en om nieuwe functionaliteit toe te voegen waaraan behoefte is. Het uiteindelijke resultaat blijft herkenbaar als StUF.
GEMMA standaardenlijst
Het doorontwikkelingspoor wordt vormgegeven door het realiseren van een StUF 3.02 onderlaag met daarbij een set aan scherpe koppelvlakstandaarden die gebaseerd zijn op de vernieuwde informatiemodellen RSGB3, RGBZ2 en ImZTC2.2.<br />
* [[GEMMA API-standaardenlijst|API-standaardenlijst]]
|titel2 = Meer informatie
|inhoud2 =
Vastgestelde standaarden op vng.nl
* [https://vng.nl/artikelen/overzicht-gemeentelijke-standaarden Overzicht gemeentelijke standaarden]


=== 1.2 Ontdekkenspoor ===
Aan de slag met API-standaarden
* [https://vng-realisatie.github.io/Standaarden/API-standaarden API-specificaties (github pages)]


Het ontdekkenspoor geeft invulling aan de wens om meer fundamenteel te vernieuwen. Uitgangspunt van het ontdekkenspoor is een architectuur die uitgaat van het (real time) bevragen van verschillende gegevensbronnen in tegenstelling tot het dupliceren van data wat aan de huidige StUF familie ten grondslag ligt. Op basis van functionele behoeften worden koppelvlakken ontwikkeld binnen het ontdekkenspoor die gebruik kunnen maken van nieuwe/andere architectuurprincipes en technieken zoals REST en JSON. Daarbij kunnen nieuwe en andere kwaliteit- en toetsingscriteria gelden dan voor de huidige StUF familie. Ook deze moeten ontdekt worden op basis van functionele behoefte.  
Nederlandse API-strategie
Functioneel maken de koppelvlakken ook binnen het ontdekkenspoor gebruik van informatiemodellen RSGB3, RGBZ2 en ImZTC2.2. Naarmate nieuwe koppelvlakken toegevoegd worden zal er ook een repository ontstaan met componenten voor hergebruik. Uiteindelijk moet dit leiden tot een StUF4 familie van standaarden. <br />
* [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]


=== 1.3 Planning en vaststelling van standaarden ===


De informatiemodellen RSGB3, RGBZ2 en ImZTC2.1 (binnenkort 2.2) zijn alle goedgekeurd door de bijbehorende expert werkgroepen. Toch hebben de nieuwe versies van deze standaarden de status ‘in ontwikkeling’. Zij krijgen de status ‘in gebruik’ wanneer ze zijn vastgesteld door de Regiegroep Gegevens en Berichten. Dit gebeurt wanneer de ‘verStUFfing’  is uitgevoerd. Met het verStUFfen wordt het vertalen bedoeld van het informatiemodel naar (StUF) XML structuren die gebruikt kunnen worden voor het uitwisselen van de gegevens tussen applicaties. Deze XML structuren worden berichten gebruikt die op hun beurt weer onderdeel uitmaken van koppelvlakstandaarden. Naar aanleiding van het verStUFfen kunnen nog aanpassingen doorgevoerd worden op de informatiemodellen.
|hoogte = 350px
De verStUFfing vindt plaats als onderdeel van de ontwikkeling van StUF 3.02 (spoor doorontwikkeling De vaststelling  van StUF 3.02 vindt plaats wanneer er een eerste koppelvlak wat op deze onderlaag gebaseerd is wordt vastgesteld.<!-- Page revision date: 2017-05-01T06:05:19Z -->
}}
{{Publicatie
|Paginastatus=publiceren
|Redactiestatus=Actueel
|Wikibeheerder=GEMMA Beheer
}}
[[Category:Standaarden paginas]]

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

GEMMA standaardenlijst

Meer informatie
Vastgestelde standaarden op vng.nl

Aan de slag met API-standaarden

Nederlandse API-strategie

Een computerprogramma om een specifieke taak uit te voeren die geen betrekking heeft op de werking van de computer zelf.

Afkorting van 'application programming interface': een manier om twee of meer computerprogramma's met elkaar te laten communiceren. Het is een soort software-interface die een dienst aanbiedt aan andere stukjes software.

Een meervoudig te gebruiken registratie met betrouwbare data

Afkorting voor de Representational State Transfer architectuurstijl voor gedistribueerde hypermedia systemen

Een document met erkende afspraken, specificaties of criteria over een product, een dienst of een methode.

Weergave van een feit, begrip of aanwijzing, geschikt voor overdracht, interpretatie of verwerking door een persoon of apparaat.

De mate waarin de organisatie zich voor de informatievoorziening kan verlaten op een informatiesysteem. De betrouwbaarheid van een informatiesysteem is daarmee de verzamelterm voor de begrippen beschikbaarheid, integriteit en vertrouwelijkheid.

Het opleggen van een bepaalde norm of standaard voor het ontwerp, de constructie, het testen of gebruiken van een product of proces.

Het geheel van mensen, middelen en maatregelen, gericht op de informatiebehoefte van de organisatie.

De fundamentele concepten of eigenschappen van een systeem in zijn omgeving belichaamd in zijn elementen, relaties en in de principes van zijn ontwerp en evolutie.

Normatieve en descriptieve documenten die huidige/toekomstige architectuur van een organisatie/domein schetsen.

De GEMeentelijke ModelArchitectuur met een verzameling samenhangende kaders, richtlijnen, referentiemodellen en standaarden die gemeenten helpt bij het inrichten van hun IT-omgeving en processen.

Betekenisvolle gegevens.

Overgenomen van "https://www.gemmaonline.nl/index.php?title=API-standaarden&oldid=1062607"
Deze pagina is het laatst bewerkt op 30 apr 2024 om 15:24.