Moderne overheid vraagt om moderne API’s

Wat hebben bol.com, Facebook, TomTom, Pokémon Go, Netflix en Marktplaats met elkaar gemeen? Hun informatie is te benaderen en te ontsluiten via API’s. Het eenvoudig uitwisselen van informatie is voor deze bedrijven belangrijk om gebruikers snel te bedienen en gegevensstromen efficiënt te laten verlopen. Daarvoor moeten verschillende applicaties goed met elkaar kunnen communiceren en dan komt de API om de hoek kijken. Een Application Programming Interface (API) is een combinatie van het ‘fysieke’ koppelvlak in een applicatie en de technische bestanden en documentatie die uitleggen hoe dat koppelvlak communiceert met andere applicaties.

Hoe om te gaan met API’s klinkt misschien als een puur operationeel vraagstuk. Het is echter ook strategisch, omdat het inzetten van API’s ook gaat over hoe digitale diensten te ontsluiten, hoe deze met elkaar te combineren en hoe de informatiehuishouding in te richten. Vragen die voor de overheid van belang zijn om regelmatig bij stil te staan. Voor de overheid is het gebruik van API’s voor berichtenuitwisseling niet nieuw. Zo worden bijvoorbeeld al API’s gebruikt die zijn gebaseerd op de standaarden Digikoppeling en StUF (Standaard UitwisselingsFormaat). Deze kennen hun oorsprong vóór 2008. In die tijd was de standaard SOAP dominant waardoor de meeste overheidsstandaarden voor API’s op SOAP zijn gebaseerd. SOAP-standaarden zijn gespecialiseerd in zware beveiliging en complexe gegevensuitwisseling. Rond 2008 vond wereldwijd een omslag plaats richting de RESTful API. Deze viel samen met de opkomst van social media-platforms als Facebook en Twitter en de introductie van smartphones en tablets. Hiervoor zijn snelheid en flexibiliteit van gegevensuitwisseling belangrijk, wat SOAP niet kan bieden en RESTful API’s wel. Met ‘API’s’ worden hieronder RESTful API’s bedoeld.

Dienstverlening

Waarom zijn API’s sinds 2008 zo populair? API’s zijn de motor achter twee trends die in 2008 begonnen. De social media-‘platforms’ en het einde van het monopolie van de internetbrowser. Om met die laatste te beginnen; de interactie tussen aanbieder en gebruiker is veranderd, van één kanaal zijn we naar vele kanalen gegaan: apps op telefoons en tablets, smart TV’s, wearables, the internet of things. Alle nieuwe kanalen gebruiken API’s om diensten met elkaar te integreren. Tegelijkertijd was er de opkomst van de social media-platforms die via API’s hun functionaliteit graag aan anderen ter beschikking stellen, zoals Google Maps dat geïntegreerd is in veel andere producten.
Het succes van deze twee trends is mede te danken aan de kerneigenschappen van API’s, namelijk eenvoud, bruikbaarheid en schaalbaarheid. Deze eigenschappen maken het voor een platform goed mogelijk om data en diensten beschikbaar te stellen. Hierdoor ontstaan nieuwe producten, worden gebruikers op verschillende manieren bereikt en is data te ontsluiten via verschillende kanalen.

In de praktijk redeneert de overheid voor systemen die interacteren met burger en bedrijf regelmatig alleen vanuit de lang gevestigde overheidsstandaarden. Langdurige projecten worden opgetuigd om achterliggende systemen te integreren en burgers worden nog vaak van de ene portal naar de andere geleid. Dit sluit totaal niet aan bij wat de burger inmiddels gewend is van de commerciële platforms. Alleen door het gebruik en het beschikbaar stellen van API’s op beleidsniveau aan te pakken komt hier verandering in. Zo pakt bijvoorbeeld de Omgevingswet het al anders aan.

De Omgevingswet

Een uitgangspunt in de Omgevingswet is dat de gebruiker (burger of bedrijf) die bijvoorbeeld een vergunning aanvraagt, over dezelfde informatie beschikt als de overheid die de vergunning beoordeelt. Ook moeten burgers en bedrijven op een moderne manier met de overheid kunnen interacteren. Niet alleen via een overheidswebsite, maar ook via apps op telefoons en tablets. Deze apps hoeven niet noodzakelijk door overheden te zijn ontwikkeld, want voor iedereen moet het mogelijk zijn om voor de Omgevingswet nieuwe applica- ties te ontwikkelen. Dit kan door API’s met omgevingswetinformatie en -functionaliteit (niet alleen data) aan iedereen ter beschikking te stellen. Door de Omgevingswet wordt er geredeneerd vanuit de gebruiker en actief beleid gevoerd om interactie op basis van API’s mogelijk te maken.

Interne organisatie

Het concept van API’s biedt ook in de backoffice grote voordelen. Maar dat doen we toch al jaren, zal de geïnformeerde lezer zich terecht afvragen. Het klopt dat op basis van de bestaande overheidsstandaarden al vele jaren (op SOAP gebaseerde) API’s worden toegepast. Dit zie je bijvoorbeeld terug bij gemeentelijke systeemintegratie. Voor een aantal daarvan worden moderne API’s toegepast, maar bijvoorbeeld het bevragen van een gegevensmagazijn kan een stuk beter, zoals bleek uit een rapport van de Software Improvement Group. Er is dus ook winst te behalen door bestaande (SOAP) API’s te bekijken in het licht van de huidige wereldwijde trends.

Als anderen jouw API gebruiken heb je een breder bereik

De boodschap is hierbij niet dat in de backoffice overal meteen RESTful API’s gebruikt moeten worden. Voor sommige vormen van uitwisseling is SOAP nog steeds beter, voor andere is een migratie naar REST te duur. Het vervangen van systemen en opbouw van kennis vraagt een investering die niet in één keer gedaan kan worden.

De toepassing

Hoe gaan we in de praktijk om met API’s? Vaak worden deze beschikbaar gesteld via een website of via een API-portal. Zo stelt bol.com een API beschikbaar via een developers portal. Binnen de overheid komt data.overheid.nl daarbij in de buurt. Het publiceren van API’s gebeurt binnen de overheid echter weinig en als het gebeurt gaat het of om ingewikkelde koppelingen of zijn ze niet gebruiksvriendelijk. Publicatie gebeurt dan bijvoorbeeld in de vorm van een ‘setje links’, waarbij de gebruiker (lees programmeur) zelf moet uitzoeken wat te gebruiken.
De platforms, zoals Google, Twitter, LinkedIn en Facebook, pakken het heel anders aan. Daar weten ze dat je alleen grootschalig gebruik van API’s krijgt door het programmeurs van andere partijen zo makkelijk mogelijk te maken. Als anderen jouw API gebruiken in hun producten heb je immers een breder bereik en is de kans op meer gebruikers of klanten groter. De meeste platforms leveren dan ook voorzieningen mee als softwareontwikkelaars aan de slag willen met hun API. De overheid kan hiervan leren, want als het hergebruik van ICT-voorzieningen belangrijk is, dan is een goede aansluiting op marktontwikkelingen nodig en moet je gebruikers optimaal faciliteren.

Conclusie

De overheid sluit nog te weinig aan op het verwachtingspatroon van burgers en bedrijven. Ze maken niet alleen meer gebruik van een webbrowser voor digitale dienstverlening en verwachten naadloze integratie met andere platformen en gadgets die ze gebruiken. Door beter beleid te voeren op het beschikbaar stellen van API’s kan de overheid aan deze verwachtingen gaan voldoen. Als bijvangst kan ook de backoffice hier nog voordelen van meepikken. Een belangrijke les is wel dat je moet denken aan twee soorten gebruikers: de eindgebruiker en de softwareontwikkelaar. Die laatste zorgt er uiteindelijk weer voor dat de overheidsdiensten beter zijn te integreren in andere platforms en dat overheidsdata beter herbruikbaar zijn. Helaas gebeurt dit in de praktijk te weinig en worden er vanuit de overheid niet tot nauwelijks API’s gepubliceerd. Vaak kiest men ook voor de veilige weg met bestaande legacy-technologie.

Frank Terpstra is senior consultant bij Enable-U en adviseur bij Geonovum.
Lancelot Schellevis is adviseur interoperabiliteit bij Bureau Forum Standaardisatie.

De komende maanden organiseert het Forum Standaardisatie in samenwerking met de NORA een aantal themabijeenkomsten over API’s. Houd daarvoor de website van het Forum in de gaten.