Het Open Geospatial Consortium (OGC) is een internationale standaardenorganisatie. Hier komen onder andere de OGC API standaarden vandaan: gestandaardiseerde REST APIs die ervoor zorgen dat geodata op een universele manier geserveerd en gebruikt kan worden. Regelmatig organiseert het OGC code sprints: hackathons van drie dagen waar standaarden-experts en ontwikkelaars de OGC standaarden implementeren in software. De OGC standaarden die geimplementeerd worden zijn dan meestal nog in draft; wel stabiel, maar nog niet officieel goedgekeurd. Op basis van de feedback van ontwikkelaars kunnen OGC standaarden-experts meteen de standaarden verbeteren en aanvullen. Zo wordt het ontwikkelen van standaarden net iets meer agile.

Binnen de publieke sector groeit de behoefte aan goed gedocumenteerde, interoperabele en toekomstbestendige API's. De REST API Design Rules (ADR) vormen daarbij een belangrijk referentiekader: ze stimuleren eenvoud, voorspelbaarheid en brede toepasbaarheid door gebruik te maken van open standaarden.

Regelmatig komt de vraag voorbij of OData, een specificatie ontwikkeld binnen het Microsoft-ecosysteem, een slimme keuze kan zijn voor publieke API's. In dit artikel analyseren we de voor- en nadelen van OData, met nadruk op eenvoud, interoperabiliteit en vendor-neutraliteit. Ook bekijken we hoe OData zich verhoudt tot de ADR, en op welke vlakken deze conflicteren.

In een tijd waarin digitale overheidsdiensten steeds vaker via REST API’s communiceren, is het waarborgen van de veiligheid van deze interfaces cruciaal. WuppieFuzz, ontwikkeld door TNO, is een open-source, coverage-guided fuzzer die specifiek is ontworpen voor het testen van REST API’s. Het doel: kwetsbaarheden en bugs opsporen voordat ze misbruikt kunnen worden, met een sterke focus op gebruiksvriendelijkheid, modulariteit en inzichtelijkheid.

Op 31 oktober 2024 publiceerde Geonovum voor het eerst een JSON-schema bij een informatiemodel. Het betrof de publicatie van versie 3.0 van het Informatiemodel Externe Veiligheid: (IMEV). Daarnaast is er ook een suggestie voor een OpenApi Specificatie (OAS) gepubliceerd. In deze blog worden de ervaringen gedeeld die Geonovum daarmee heeft opgedaan in de hoop dat anderen daar van kunnen leren.

Ruim zeven jaar geleden werd het traject afgerond om de OpenAPI Specification (OAS) op de pas-toe-leg-uit-lijst van het Forum Standaardisatie te krijgen. Sindsdien is versie 3.0 de verplichte standaard voor overheids-API's. En dat was nog steeds zo, ondanks dat de volgende versie 3.1 al lang beschikbaar is. Tot deze week. Het standaardisatieproces voor OpenAPI 3.1 is eindelijk hervat. In deze blogpost leggen we uit waarom dit een belangrijke stap is waar veel ontwikkelaars op hebben gewacht.

Ondergetekende met het bewijs dat OpenAPI verplicht werd gesteld voor REST API's van de overheid, ruim zeven jaar geleden.

Het API-register krijgt een flinke upgrade. We kiezen bewust voor een REST-only en OpenAPI-first aanpak, zodat we optimaal kunnen profiteren van moderne standaarden en tooling. Dit levert niet alleen voordelen op voor ontwikkelaars, maar zorgt ook voor een eenvoudiger, consistenter en toekomstbestendig register. In deze blog lees je welke keuzes we maken, waarom we daarvoor kiezen en welke nieuwe mogelijkheden het API-register straks biedt.

De 131ste Open Geospatial Consortium (OGC) - Technical Committee (TC) meeting vond plaats van 3 tot 6 maart 2025 in Rome, Italië. Het was een evenement voor professionals in de GIS industrie om samen te werken aan de toekomst van Geo- standaarden en technologieën. Namens Geonovum waren Frank Terpstra en Linda van den Brink aanwezig en hebben zij verslag gedaan van de belangrijkste inzichten.

Op woensdagmiddag 26 maart 2025 kwam het Kennisplatform API's bijeen om de laatste ontwikkelingen rond API's te bespreken. Hier presenteerde ik een update over de API Design Rules (ADR), waarvan de 2.0 versie is ingediend bij het Forum Standaardisatie om op de 'Pas toe of leg uit'-lijst (PTOLU) te zetten. Tevens lichtte ik toe wat Logius als beheerder doet om de standaard verder te brengen en hoe wij toe werken naar een 2.1 versie. Hierbij is de symbiose tussen developer.overheid.nl, het Kennisplatform en de ADR van belang voor een succesvolle toekomst.

Als je gaat starten met het ontwikkelen van een API zijn er verschillende manieren om dit aan te pakken. In de praktijk zie je grofweg 2 verschillende methoden: "design-first" en "code-first". In dit artikelen leggen we uit wat de verschillen zijn en waarom de "design-first" aanpak wat ons betreft de voorkeur heeft.