Thema Werken met API's: verschil tussen versies

Inhoud

1 API-referentiearchitectuur (ARA)
- 1.1 Aanleiding en belang
2 Inhoud
- 2.1 Eerste stappen: veilig en transparant werken met API's
- 2.2 Vervolg: ARA
  - 2.2.1 Eerste resultaten
  - 2.2.2 Bijeenkomst met gemeenten en leveranciers

Huidige versie van 6 okt 2023 om 06:50

API-referentiearchitectuur (ARA)[bewerken]

In 2017 zijn gemeenten, VNG en leveranciers onder de naam ‘Common Ground’ een nieuwe informatiekundige weg ingeslagen. Eén gevolg was het ontwikkelen van nieuwe API-standaarden die aansluiten bij het vijflagenmodel en de REST-architectuurstijl volgen.

Naar aanleiding van de eerste ervaringen met implementatie van deze standaarden is een aantal vraagstukken ontstaan dat niet gaat over individuele standaarden, maar raakt aan alle API-standaarden voor gemeenten.

Het gaat hierbij om concrete opgaven als het bepalen van de aanpassingen van API-standaarden om aan te kunnen sluiten bij eerder dit jaar beschreven oplossingen voor toegangsbeheer. Maar ook om het beantwoorden van meer fundamentele vragen bij thema’s als performance (bij het bevragen van gegevens uit meerdere bronnen ineens) en consistentie (tussen gegevens in meerdere bronnen).

Het antwoord op deze vragen vormt een gezamenlijke basis of ‘fundament’ waarop we de komende jaren bij de ontwikkeling van API-standaarden verder kunnen bouwen. Dit fundament noemen we de API-referentiearchitectuur (ARA). Ontwikkeling daarvan is een voorwaarde voor doelmatige, op elkaar aansluitende API-standaarden van goede kwaliteit.

Aanleiding en belang[bewerken]

Standaarden vormen een essentiële schakel in de transitie naar een informatievoorziening die aansluit bij de visie Common Ground. Dit belang wordt ondersteund door het recent (april 2022) door PBLQ uitgebrachte advies over 'versterking van bestuurlijke sturing op Common Ground' en het verslag van de meerdaagse Common Ground (september 2022). In beide documenten komen we dan ook veelvuldig begrippen als 'uitwisseling', 'bronnen' en natuurlijk 'standaarden' tegen.

Wordcloud met begrippen uit het rapport van PBLQ over bestuurlijke sturing Common Ground (links) en het verslag van de meerdaagse Common Ground (rechts)

Naar aanleiding van implementatie door gemeenten van de eerste API-standaarden die de REST-architectuurstijl volgen, constateren we echter een aantal problemen aan die niet zozeer te maken hebben met individuele API-standaarden als wel met de meer generieke vraag hoe hoe je binnen de beperkingen van deze stijl nu eigenlijk een goede standaard ontwikkelt. Denk hierbij aan issues als:

onvoldoende performance om standaarden in de praktijk te kunnen gebruiken;
(te) grote complexiteit van het uitvoeren van veelvoorkomende handelingen;
onduidelijkheid over transacties en het waarborgen van consistentie.

Bij ieder van de bovenstaande zaken zijn ‘reparatie-acties’ te bedenken: oplossingen die snel te realiseren zijn en op korte termijn de ergste nood lenigen. Gemeenten en marktpartijen zijn hier – logischerwijs – ook mee bezig. Maar we willen voorkomen dat we, in de haast om zaken werkend te krijgen, te kort door de bocht gaan. Dus niet later concluderen dat een gekozen oplossing toch ongewenste neveneffecten met zich mee blijkt te brengen, of alleen in één specifieke situatie toepasbaar is. We zoeken kortom duurzame, herbruikbare oplossingen bij de gevonden problemen. We gaan daartoe:

goed luisteren naar gemeenten en marktpartijen om te horen waar ze tegenaan lopen en wat er volgens hen nodig is om dat op te lossen;
op basis daarvan de Common Ground doelarchitectuur verder uitwerken, te beginnen daar waar die raakt aan bovengenoemde problemen;
beschrijven welke patronen er zijn om de huidige en toekomstige uitdagingen bij gedistribueerde gegevensopslag aan te kunnen gaan;
samen met gemeenten en leveranciers hierin keuzes maken.

Tijdens deze activiteiten willen we een aantal vragen beantwoorden, waaronder:

welke soorten API’s onderscheiden we, en waarvoor worden deze gebruikt?ontwerpen we API’s taak- of data-gericht (of, afhankelijk van omstandigheden allebei)?
wat is de gewenste omvang of granulariteit van een API of resource?
welke interactiepatronen voor compositie van API’s of orkestratie en choreografie van services kunnen we onderscheiden?
hoe richten we (als vervolg op de bevindingen van eerder dit jaar) modern Identity en Acces Management in een API-landschap in?

Inhoud[bewerken]

Eerste stappen: veilig en transparant werken met API's[bewerken]

Eerder is gewerkt aan oplossingspatronen voor Identity en Access Management in een API-landschap. De resultaten hiervan zijn te vinden op GitHub.

Vervolg: ARA[bewerken]

De API-referentiearchitectuur (ARA) moet niet alleen gaan beschrijven hoe gemeenten binnen hun informatievoorziening gebruik kunnen maken van API's, maar ook welke uitgangspunten en principes ontwerpers van API-standaarden (zoals de VNG) zouden kunnen hanteren bij het ontwerpen daarvan.

Omdat deze uitgangspunten en principes van invloed zijn op bijvoorbeeld de performance die van een API verwacht kan worden, zijn deze niet alleen belangrijk voor API-ontwerpers, maar ook voor gemeenten en hun leveranciers die ze immers moeten implementeren.

Eerste resultaten[bewerken]

De eerste onderdelen van ARA zijn ondertussen opgeleverd. Het gaat hierbij om een bird's eye view waarin enkele (kern) concepten worden geduid waarmee bij het ontwerp van API's en API-standaarden rekening gehouden moet worden, en een verkenning naar de implicaties van distributie van gegevens over meerdere API's waar die gegevens in samenhang worden bevraagd of in één transactie worden vastgelegd. Deze resultaten zijn gebundeld in een powerpointpresentatie.

Bijeenkomst met gemeenten en leveranciers[bewerken]

Naar aanleiding van internationale ‘best practices’ en bijbehorende voor- en nadelen hebben we aan gemeenten en leveranciers een aantal stellingen voorgelegd die te maken hebben met fundamentele keuzes die we moeten maken om te komen tot een coherent API-landschap te komen. Hoe denken we bijvoorbeeld over convenience API’s en gedeelde databases? Hebben we daarbij een gezamenlijke voorkeur?

Vervolgens werd gekeken naar onderwerpen die volgens de aanwezigen verdere uitwerking verdienen. Daarbij werd aan de volgende thema’s prioriteit gegeven: het stap-voor-stap uitwerken van een API Referentie Architectuur (ARA), domeinafbakening en een verder uitgewerkte oplossing voor autorisaties waarbij onze API-standaarden aansluiten.

Over deze bijeenkomst hebben we een blog geschreven, die te lezen is op de Common Ground-website.

Deze pagina is het laatst bewerkt op 6 okt 2023 om 06:50.

@@ Regel 1: / Regel 1: @@
-{{Cocreatie
+{{Publicatie
-|Cocreatiepublicatie=Cocreatie
+|Paginastatus=publiceren
 |Redactiestatus=Actueel
-|GEMMAOnlinebeheerder=Beheerder Standaarden,
+|Wikibeheerder=Beheerder Standaarden
-|DenkMeeCategorie=Thema
 }}
+==API-referentiearchitectuur (ARA)==
-''De eerste onderdelen van de 'Referentiearchitectuur Werken met API's' zijn ondertussen gepubliceerd in [https://vng-realisatie.github.io/RAWA/ de gelijknamige GitHub-repository]. De inhoud van deze repository wordt in de volgende fase van het project opgenomen in de GEMMA-architectuur.''
+[[Bestand:Ara.png|miniatuur|rechts]]
-==Referentiearchitectuur veilig en transparant werken met API’s==
-Het afgelopen jaar zijn de eerste gemeenten gestart met het implementeren van API-standaarden, zoals de API-standaarden voor zaakgericht werken. Veel andere gemeenten zijn bezig daarvoor plannen te maken. Hierbij is het duidelijk geworden dat het werken met API’s meer betekent dan alleen het vervangen van de ene standaard door de andere. Vraagstukken, zoals die rondom beveiliging van API-standaarden en transparantie over verwerkingen, vereisen nieuwe antwoorden die zijn toegespitst op de specifieke context van een API-landschap. Antwoorden die passen bij bestaande én nog te ontwikkelen API-standaarden en bovendien aansluiten bij oplossingen van andere overheden. Vandaar het voorstel voor het ontwikkelen van een ‘referentiearchitectuur veilig en transparant werken met API’s’.
-===Aanleiding===
-De door gemeenten en VNG opgestelde informatiekundige visie Common Ground beoogt een modernisering van de gemeentelijke informatievoorziening. Er wordt gestreefd naar een wendbare inrichting die gemeenten in staat stelt om hun processen en dienstverlening op een snelle en flexibele manier te verbeteren. Collectieve standaardisatie van met name de toegang tot, en de modellering van, gegevens is daarvoor nodig.
-Kern van de strategie om te komen tot realisatie van deze informatiekundige visie is het scheiden van de gegevens die binnen processen worden gebruikt van de logica en presentatie die daarbij een rol speelt. Gegevens worden zo breed als mogelijk beschikbaar gesteld en kunnen, binnen de grenzen van wet- en regelgeving, voor verschillende doelen worden gebruikt. Hierbij worden verschillende applicatiecomponenten gebruikt die zelfstandig functioneren en gestandaardiseerd gegevens uitwisselen. Daarbij wordt maximaal gebruik gemaakt van gegevens uit bronregistraties.
-Met de transitie naar deze informatiekundige visie zullen gemeenten in toenemende mate gebruik maken van gegevensdiensten (APIs) voor het ophalen en muteren van brongegevens en het ontvangen van notificaties over plaatsgevonden gebeurtenissen rondom die bronregistraties. Ook zullen gemeenten in toenemende mate zelf APIs gaan aanbieden voor zowel in- als extern gebruik.
-Nu een aantal standaard API-standaarden zijn gerealiseerd en vastgesteld (oa Zaakgericht werken en een aantal HaalCentraal API’s) worden deze door steeds meer gemeenten in gebruik genomen. Gemeenten hebben behoefte aan een referentiearchitectuur waarin is beschreven welke referentiecomponenten nodig zijn en hoe ze moeten worden ingericht om veilig en transparant met API's te kunnen werken. Waarbij er ruimte blijft voor lokaal beleid en er dus verschillende technische implementaties mogelijk blijven. In aanvulling op de uitbreiding van de GEMMA referentiearchitectuur worden handreikingen voor specifieke situaties gemaakt.
-===Overheidsbrede ontwikkelingen===
-Bij het ontwikkelen van een ‘referentiearchitectuur veilig en transparant werken met API’s’ hoeven we niet bij nul te beginnen. Op overheidsbreed niveau zijn over dit onderwerp al de nodige uitgangspunten, aanbevelingen en beschrijvingen samengebracht en beschreven.
-[[Bestand:Componenten voor veilig werken met API's.png|miniatuur|Componenten voor veilig werken met API's (overgenomen uit hoofdstuk Architectuur Nederlandse API-strategie)]]
-Binnen de NORA (Nederlandse Overheids Referentiearchitectuur) wordt het thema [https://www.noraonline.nl/wiki/Identity_%26_Access_Management_(IAM) Identity en Access Management (IAM)] uitgewerkt. Naast een [https://www.noraonline.nl/wiki/Begrippen_IAM begrippenkader] worden daar bijv. aanbevelingen gedaan over de plaats van identificatie, authenticatie en autorisatie binnen architectuur en het ontwerp van diensten.
-Specifiek gericht op het werken met API’s is het [https://geonovum.github.io/KP-APIs/API-strategie-algemeen/#architectuur hoofdstuk architectuur] dat door het Kennisplatform API’s als onderdeel van de Nederlandse API-strategie in concept is gepubliceerd.  Zo wordt in het hoofdstuk ‘[https://geonovum.github.io/KP-APIs/API-strategie-algemeen/#api-security-architectuur API Security Architectuur]’ bijvoorbeeld beschreven welke componenten nodig zijn om veilig met API’s te kunnen werken. Op het Kennisplatform vindt u ook een aantal '[https://www.geonovum.nl/themas/kennisplatform-apis Masterclasses]' waarin kennis wordt gedeeld over het verantwoord maken en gebruiken van API's.
-Ook projecten waarbij intensief van API's gebruik wordt gemaakt zijn bijdrages geleverd waarvan organisaties gebruik kunnen maken om binnen hun eigen context te komen tot veilig en transparant API-gebruik (bijv. een [https://vng-realisatie.github.io/Haal-Centraal/ handreiking] voor gebruikers van Haal Centraal API's).
-===Resultaat===
-De op te leveren ‘referentiearchitectuur veilig en transparant werken met API’s’ gaat een aantal producten omvatten, waaronder:
-# Best practices bij gemeenten;
-# Uitbreiding van de GEMMA referentiearchitectuur;
-# Uitbreiding van het GEMMA Gegevenslandschap;
-# Beschrijving van verschillende inrichtingsscenario’s.
-[[Bestand:Samenhang onderdelen referentiearchitectuur.svg|miniatuur|Samenhang tussen de verschillende onderdelen van de referentiearchitectuur Werken met API's]]
-====1 Best practices bij gemeenten====
+In 2017 zijn gemeenten, VNG en leveranciers onder de naam ‘Common Ground’ een nieuwe informatiekundige weg ingeslagen. Eén gevolg was het ontwikkelen van nieuwe API-standaarden die aansluiten bij het vijflagenmodel en de REST-architectuurstijl volgen.
-Er zijn nu al diverse gemeenten die zelf, of met hulp van een leverancier, een landschap hebben ingericht voor het werken met identiteiten, autorisaties en API’s. De bestaande inrichtingen kunnen worden opgenomen op de GEMMA als (best) practices, waarbij beschreven wordt hoe ze zich verhouden tot de inrichtingsscenario’s.
+Naar aanleiding van de eerste ervaringen met implementatie van deze standaarden is een aantal vraagstukken ontstaan dat niet gaat over individuele standaarden, maar raakt aan alle API-standaarden voor gemeenten.
-====2 Uitbreiding GEMMA-referentiearchitectuur====
+Het gaat hierbij om concrete opgaven als het bepalen van de aanpassingen van API-standaarden om aan te kunnen sluiten bij eerder dit jaar beschreven [https://github.com/VNG-Realisatie/RAWA/ oplossingen voor toegangsbeheer]. Maar ook om het beantwoorden van meer fundamentele vragen bij thema’s als performance (bij het bevragen van gegevens uit meerdere bronnen ineens) en consistentie (tussen gegevens in meerdere bronnen).
-In de GEMMA modelarchitectuur worden binnen de informatiearchitectuur referentiecomponenten beschreven. Deze referentiecomponenten zijn modulair, zelfstandig inzetbaar en vervangbare delen van softwaresystemen. Referentiecomponenten groeperen logisch bij elkaar horende functionaliteit en bieden deze functionaliteit aan via goed gedefinieerde interfaces.
+Het antwoord op deze vragen vormt een gezamenlijke basis of ‘fundament’ waarop we de komende jaren bij de ontwikkeling van API-standaarden verder kunnen bouwen. Dit fundament noemen we de API-referentiearchitectuur (ARA). Ontwikkeling daarvan is een voorwaarde voor doelmatige, op elkaar aansluitende API-standaarden van goede kwaliteit.
-Applicatiefuncties en componenten voor ‘identity- and access management’ zijn in de GEMMA-referentiearchitectuur op dit moment niet in detail uitgewerkt. De enige applicatiefunctie binnen de ‘Gedeelde generieke functionaliteit’ die direct aan dit taakgebied is gerelateerd is ‘Registreren en delen van identiteiten en autorisaties’. Aan deze functie is de Referentiecomponent ‘Gebruikersbeheercomponent’ toegewezen. Bij transparant werken hoort de applicatiefunctie ‘Registreren en delen van loggegevens’ en de toegewezen referentiecomponent ‘Loggingcomponent’. Genoemde bedrijfsfuncties en referentiecomponenten zijn in het model hierboven blauw respectievelijk groengekleurd.
+===Aanleiding en belang===
+Standaarden vormen een essentiële schakel in de transitie naar een informatievoorziening die aansluit bij de visie Common Ground. Dit belang wordt ondersteund door het recent (april 2022) door PBLQ uitgebrachte advies over [https://vng.nl/sites/default/files/2022-07/20220423-PBLQ-VNG-Advies-versterken-bestuurlijke-sturing-Common-Ground.pdf 'versterking van bestuurlijke sturing op Common Ground'] en [https://commonground.nl/attachment/1dd00564-a50c-4dc7-8c95-99fbd60612aa het verslag van de meerdaagse Common Ground] (september 2022). In beide documenten komen we dan ook veelvuldig begrippen als 'uitwisseling', 'bronnen' en natuurlijk 'standaarden' tegen.
-[[Bestand:Gedeelde generieke applicatiefuncties en bijbehorende referentiecomponenten in de GEMMA-referentiearchitectuur.svg|miniatuur|center|800px|Gedeelde generieke applicatiefuncties en bijbehorende referentiecomponenten in de GEMMA-referentiearchitectuur]]
+[[Bestand:Wordcloud rapport PBLQ CG en driedaagse.png|miniatuur|460px|Wordcloud met begrippen uit het rapport van PBLQ over bestuurlijke sturing Common Ground (links) en het verslag van de meerdaagse Common Ground (rechts)]]
-Gelet op de Nederlandse API-strategie is het nodig om de GEMMA-referentiearchitectuur te actualiseren en met nieuwe componenten uit te breiden (wat ook leidt tot het opnemen daarvan in de GEMMA Softwarecatalogus).
+Naar aanleiding van implementatie door gemeenten van de eerste API-standaarden die de REST-architectuurstijl volgen, constateren we echter een aantal problemen aan die niet zozeer te maken hebben met individuele API-standaarden als wel met de meer generieke vraag hoe hoe je binnen de beperkingen van deze stijl nu eigenlijk een goede standaard ontwikkelt. Denk hierbij aan issues als:
+* onvoldoende performance om standaarden in de praktijk te kunnen gebruiken;
+* (te) grote complexiteit van het uitvoeren van veelvoorkomende handelingen;
+* onduidelijkheid over transacties en het waarborgen van consistentie.
-====3 Bijwerking GEMMA Gegevenslandschap====
+Bij ieder van de bovenstaande zaken zijn ‘reparatie-acties’ te bedenken: oplossingen die snel te realiseren zijn en op korte termijn de ergste nood lenigen. Gemeenten en marktpartijen zijn hier – logischerwijs – ook mee bezig. Maar we willen voorkomen dat we, in de haast om zaken werkend te krijgen, te kort door de bocht gaan. Dus niet later concluderen dat een gekozen oplossing toch ongewenste neveneffecten met zich mee blijkt te brengen, of alleen in één specifieke situatie toepasbaar is. We zoeken kortom duurzame, herbruikbare oplossingen bij de gevonden problemen. We gaan daartoe:
+* goed luisteren naar gemeenten en marktpartijen om te horen waar ze tegenaan lopen en wat er volgens hen nodig is om dat op te lossen;
+* op basis daarvan de Common Ground doelarchitectuur verder uitwerken, te beginnen daar waar die raakt aan bovengenoemde problemen;
+* beschrijven welke patronen er zijn om de huidige en toekomstige uitdagingen bij gedistribueerde gegevensopslag aan te kunnen gaan;
+* samen met gemeenten en leveranciers hierin keuzes maken.
-Het GEMMA Gegevenslandschap is de doelarchitectuur die is opgesteld om als gemeenten samen met andere partijen de informatiekundige visie Common Ground te kunnen realiseren. Er wordt gebruik gemaakt van een architectuurmodel dat is opgedeeld in een vijftal architectuurlagen. Per laag van het model zijn de functies beschreven die voor de betreffende laag van belang zijn. Binnen het GEMMA Gegevenslandschap zijn op hoofdlijnen beschrijvingen opgenomen ten aanzien van authenticatie, autorisatie en betrouwbaarheidsniveaus van diensten. Bijv. in de handreikingen voor ‘[https://www.gemmaonline.nl/images/gemmaonline/7/75/GEMMA_Gegevenslandschap_-_Autorisatie_en_authenticatie_v1_0.pdf Authenticatie en Autorisatie]’ en ‘[https://www.gemmaonline.nl/images/gemmaonline/9/93/20191022_-_API_beveiligingsrichtlijnen_V093.pdf Beveiligingsrichtlijnen voor API's en webservices]’.
+Tijdens deze activiteiten willen we een aantal vragen beantwoorden, waaronder:
+* welke soorten API’s onderscheiden we, en waarvoor worden deze gebruikt?ontwerpen we API’s taak- of data-gericht (of, afhankelijk van omstandigheden allebei)?
+* wat is de gewenste omvang of granulariteit van een API of resource?
+* welke interactiepatronen voor compositie van API’s of orkestratie en choreografie van services kunnen we onderscheiden?
+* hoe richten we (als vervolg op de bevindingen van eerder dit jaar) modern Identity en Acces Management in een API-landschap in?
-Enkele aspecten die hierbij worden meegenomen:
+==Inhoud==
-* Rol- en attribuut-gebaseerd autoriseren (incl. consequenties ten aanzien van AVG-compliance);
-* Koppeling van betrouwbaarheidsniveau van diensten aan de niveaus van authenticatiemiddelen;
-* Inrichting van sleutel/geheimenbeheer;
-* Implementatie van autorisaties bij gegevensdiensten (bv via JWT-token scopes; al ontwikkelde wijze van autoriseren van o.a. ZGW-, Haal Centraal en Verwerkingenlogging worden meegenomen);
-* Beheer van identiteiten en autorisaties in (combinaties van) on-premise en cloudomgevingen.
-====4 Inrichting- en implementatiescenario’s====
+===Eerste stappen: veilig en transparant werken met API's===
+Eerder is gewerkt aan oplossingspatronen voor Identity en Access Management in een API-landschap. De resultaten hiervan zijn te vinden [https://vng-realisatie.github.io/RAWA/ op GitHub].
-Inrichtingsscenario’s schetsen hoe gemeenten hun informatievoorziening op een nieuwe manier kunnen gaan inrichten. Implementatiescenario's beschrijven als vervolg daarop hoe in de referentiearchitectuur beschreven referentiecomponenten op verschillende manieren in de praktijk zijn toe te passen.
+===Vervolg: ARA===
+De API-referentiearchitectuur (ARA) moet niet alleen gaan beschrijven hoe gemeenten binnen hun informatievoorziening gebruik kunnen maken van API's, maar ook welke uitgangspunten en principes ontwerpers van API-standaarden (zoals de VNG) zouden kunnen hanteren bij het ontwerpen daarvan.
-Verschillende implementatiescenario’s kunnen bijvoorbeeld worden beschreven op basis van:
+Omdat deze uitgangspunten en principes van invloed zijn op bijvoorbeeld de performance die van een API verwacht kan worden, zijn deze niet alleen belangrijk voor API-ontwerpers, maar ook voor gemeenten en hun leveranciers die ze immers moeten implementeren.
-* Intensief gebruik van de Microsoft Azure stack;
-* Gebruik van een combinatie van open source componenten (bijv. NLX);
-* Mengvorm van zowel commerciële als open source producten, en
-* Toegankelijk maken via API's van interne informatiebronnen versus externe informatiebronnen.
-Bovengenoemde implementatiescenario’s zijn een voorstel en kunnen naar aanleiding van vragen of practices van gemeenten nog worden bijgesteld.
+====Eerste resultaten====
+De eerste onderdelen van ARA zijn ondertussen opgeleverd. Het gaat hierbij om een bird's eye view waarin enkele (kern) concepten worden geduid waarmee bij het ontwerp van API's en API-standaarden rekening gehouden moet worden, en een verkenning naar de implicaties van distributie van gegevens over meerdere API's waar die gegevens in samenhang worden bevraagd of in één transactie worden vastgelegd. Deze resultaten zijn gebundeld [[Media:20221122 - Sprint 1-4 - Demo.pdf|in een powerpointpresentatie]].
-==Denk mee==
+====Bijeenkomst met gemeenten en leveranciers====
-Eén van de onderdelen van de referentiearchitectuur is een beschrijving van een aantal (bestaande) practices - dit hoeven geen best practices te zijn! We zoeken nog gemeenten die hun practice willen aanleveren of op een andere manier willen bijdragen aan deze referentiearchitectuur.
+Naar aanleiding van internationale ‘best practices’ en bijbehorende voor- en nadelen hebben we aan gemeenten en leveranciers een aantal stellingen voorgelegd die te maken hebben met fundamentele keuzes die we moeten maken om te komen tot een coherent API-landschap te komen. Hoe denken we bijvoorbeeld over convenience API’s en gedeelde databases? Hebben we daarbij een gezamenlijke voorkeur?
-Interesse? Stuur een mail naar [mailto:gemmaonline@vng.nl gemmaonline@vng.nl]!
+Vervolgens werd gekeken naar onderwerpen die volgens de aanwezigen verdere uitwerking verdienen. Daarbij werd aan de volgende thema’s prioriteit gegeven: het stap-voor-stap uitwerken van een API Referentie Architectuur (ARA), domeinafbakening en een verder uitgewerkte oplossing voor autorisaties waarbij onze API-standaarden aansluiten.
-[[Categorie:GEMMA Thema's]]
+Over deze bijeenkomst hebben we een [https://commonground.nl/blog/view/0b7b2477-80d6-4982-b17e-f1445374e51b/op-naar-een-fundament-voor-api-standaarden-in-licht-van-common-ground blog geschreven, die te lezen is op de Common Ground-website].