Het is een gegeven dat bedrijven en overheid data delen met hun partners en klanten. Data zoals informatie over diensten en producten, productreviews, klantgegevens, tweets. Het aantal diensten rond dit soort data groeit. Denk bijvoorbeeld aan diensten die data aggregeren, analyseren of visualiseren voor nieuwe doeleinden Zo kunnen organisaties, zonder zelf in bezit te zijn van data, een verscheidenheid aan data combineren en eigen analyses erop loslaten. Een mooi Nederlands voorbeeld hiervan is Datagraver: zij maken in opdracht van bedrijven analyses van data, bijvoorbeeld ter ondersteuning van nieuwsberichten of voor onderzoeksrapportages.

Technisch gezien gebeurt het delen van data in de regel via een Application Programming Interface, kortweg API. Een API beschrijft de manier waarop een extern computerprogramma kan communiceren met de softwarecomponent waar data of functionaliteit achter schuil gaat. API’s zijn niks nieuws. In de eerste versie van Windows zaten al API’s voor onder andere het aanroepen van de printer. Met de komst van de smartphone apps, die veelal werken met API’s, en de recentelijke groei in dataservices, wint de API aan bekendheid. Het werken met (open) data via API’s biedt veel mogelijkheden. Enkele voorbeelden van dergelijke API’s: de Open API van Bol.com, waarmee onder andere door de catalogus van Bol.com kan worden gezocht en aanbevelingen voor producten kunnen worden opgevraagd. De NS-API, deze API biedt onder andere actuele vertrektijden, storingen en prijzen en is bijvoorbeeld toegepast in 9292.

Maar hoe ga je te werk als je data beschikbaar wilt stellen voor gebruik door derden? En hoe kun je API’s optimaal daarvoor inzetten?  En welke risico’s loop je eigenlijk bij het openstellen van data via API’s? In het programma Digital We zijn we op zoek gegaan naar een antwoord op deze vragen. Onder andere via interviews bij een zestal Nederlandse organisaties voor best practices rond het deelnemen aan deze ‘API economie’.

Best practices in de API economie

Uit ons onderzoek en de interviews komen een aantal best practises naar voren voor het delen van data met API’s.

Doelmatigheid: De belangrijkste kanttekening die de partijen plaatsen bij het delen van hun data, is het hebben van een doel, of plan, voor het delen of (her)gebruiken van data. Wil je data gebruiken om informatie uit te wisselen met partners? Voldoe je aan een verplichting om data te delen? En is het belangrijk dat de gedeelde data altijd correct geïnterpreteerd wordt? Antwoorden op deze vragen zijn nodig om  een keuze te maken over het al dan niet beschikbaar stellen van data en op welke manier. Niet alle data wordt op dezelfde manier ontsloten. Denk na wat je wil bereiken en hoe een API hieraan bij kan dragen. Soms wil je ruwe data ontsluiten, in andere gevallen wil je juist halffabricaten of zelfs eindproducten/diensten leveren. Dit bepaalt hoe de backend van de API eruit moet zien: 24/7 beschikbaarheid, welke type koppeling of juist meerdere manieren van koppelen, etc.

Gebruiksgemak: Bij het aanbieden van data via een API staat gebruiksgemak voorop. Wanneer het doel is om veel mensen te bereiken is een succesvol datastrategie onmisbaar. De data moet gemakkelijk benaderbaar zijn. Kies bijvoorbeeld voor duidelijke tags per type data dat kan worden opgevraagd in de API en zorg dat de achterliggende systemen snel werken. Denk ook aan ondersteuning van de ontwikkelaars die de API moeten inhangen in een eigen systeem, bijvoorbeeld via FAQ’s en forums.

Standaardisatie: Ruwe data uitwisselen is makkelijk, zorgen dat systemen de data ‘begrijpen’ en er op dezelfde manier mee omgaan is moeilijker. Door gebruik van een (internationale) standaard, maak je het mogelijk om de data in een standaard format aan te bieden en dat maakt het afnemen een stuk bruikbaarder. Standaardiseren is in de interne organisatie ook belangrijk voor het communiceren met en over data tussen systemen. Bijvoorbeeld als verschillende services met elkaar samenhangen in een intern proces. De achterliggende data kan dan aan elkaar worden gerelateerd.

Betrouwbaarheid: Om te betrouwbaarheid van de API te garanderen is gebruik van een asynchrone architectuur en losstaande servers aan te raden. Het is natuurlijk niet de bedoeling dat een intern proces ‘omvalt’ wanneer er veel API-calls binnenkomen.

API management: De data die je deelt via een API elk moment gemakkelijk aanpassen en aanvullen. Zodra de API in de lucht is, kan iedereen ermee aan de slag en de data gebruiken. Echter, het is wel lastig om de API-koppeling aan te passen wanneer er veel gebruikers zijn. Dit kan gemakkelijker worden door goed API management te verzorgen. Het opstellen van randvoorwaarden is een belangrijk onderdeel van API management, vooral als de diversiteit aan gebruikers toeneemt. Bedenk dat bij het aanpassen van de API gebruikersaantallen mogelijk dalen. Het is daarom belangrijk vooraf te bedenken welke manier van koppelen de beste is voor de situatie.

Risico’s

Uiteraard zijn er ook risico’s verbonden aan het delen en beschikbaar stellen van data. Deze risico’s zijn in vijf thema’s te verdelen. We lichten ze hieronder toe.

Exposure en Interpretatie: Voor anderen is ruwe data van een andere organisatie niet per se correct te duiden. Data kan complex zijn en er kunnen er fouten gemaakt worden in de interpretatie ervan. Dit risico is groter bij ruwe data dan bij geanalyseerde data. Daarnaast kunnen ook zwaktes in datasets bekend worden, met de kans om dit daarna te verbeteren: een open keuken.

Security: Openstelling van data betekend risico lopen. Zeker voor een publieke API die door meerdere afnemers gebruikt kan worden kunnen het gebruik en de consequenties van het gebruik onvoorspelbaar zijn. Er is een scala aan maatregelen die hiertegen genomen kan worden. Denk bijvoorbeeld aan ongewenst gebruik door vergelijkingssites (farming) van de data. Door toepassen van beschermde aanvraag of vragen van een klein bedrag voor de API key, kan misbruik worden ingeperkt.

Juridisch: Vanuit juridisch gezichtspunt, kunnen er haken en ogen zitten aan het delen van data. Regelgeving maakt (her)gebruiken van data soms lastig. Er zijn wel manieren om dit te tackelen, zoals de dataeigenaar laten instemmen met hergebruik. Toch weerhoudt wet- en regelgeving vaak  de inzet van data in API’s en hackathons te organiseren. Het wettelijke kader is vaak niet helder genoeg om een duidelijk kader te scheppen voor de data-mogelijkheden. Het kan ook lastig zijn om te bepalen wat wel of geen intellectueel eigendom is en of ergens dus ‘creatieve rechten’ aan vast zitten. Denk bijvoorbeeld aan het gebruik van ondertitels.

Onderhoud: Elke API heeft onderhoud nodig. Zodra de API in de lucht is wordt het publiekelijk beschikbaar. Het kan in die zin een ‘blok aan het been’ worden: gebruikers gaan eisen stellen aan de API, vragen meer functionaliteit en de servers moeten blijven draaien. Dit onderhoud behoeft uiteraard een investering, ook in menskracht. Om te zorgen dat de investering het waard is, moet het doel van de API dus helder in beeld blijven en de API worden gemanaged.

Veroudering: Een tweestrijd rond API’s zit in de veroudering van technologie. Aan de ene kant wil je zoveel mogelijk vooraf de structuur van een koppeling bepalen. Maar natuurlijk ontstaan er steeds betere manieren om te koppelen. Wisselen van aanpak is echter lastiger wanneer veel gebruikers afhankelijk zijn van een API. De vraag bij de release van een verbeterde versie is dan, wie gaat wel en niet mee? Mocht een nieuwe API de oude echt overbodig maken, overweeg dan om een oude versie af te stoten, en gebruikers te laten migreren naar de nieuwe API.

Tot slot

Geïnterviewde partijen in het kader van dit onderzoek waren bol.com, T-Mobile, Beeld en Geluid, NS, Overheid.io en Yippie! Wilt u meer weten over de API economie? Of heeft u interesse in Digital We. Neem contact op met Marlies Rikken.