Een API (Application Programming Interface) is een specificatie over hoe softwarecomponenten met elkaar communiceren.

Klassiek kennen we bijv. de API’s van het onderliggende operating system of andere systeemsoftware. Maar ook applicatie-componenten kunnen API’s toepassen om hun functionaliteit aanroepbaar te maken.  Applicaties kunnen bijvoorbeeld opgebouwd zijn in verschillende lagen, waarbij de onderliggende softwarelaag (bijv. businesslaag) zijn functionaliteit via API’s aanroepbaar stelt aan de bovenliggende laag (bijv. presentatie laag).
Of applicaties kunnen services aanroepen die geleverd worden door een andere applicatie, bijv. “geef gezinssamenstelling”. Of applicaties kunnen opgebouwd zijn in verschillende (micro-)services, waarbij de ene service zijn functionaliteit aanroepbaar stelt aan andere services via API’s.

Een API is dus een specificatie die bepaalt welke gegevenselementen (of objecten) bij de aanroep en bij het antwoord, uitgewisseld worden en hoe deze gestructureerd zijn. Deze specificatie steunt meestal op een internationale standaard die betrekking heeft op formaat (bijv. XML, SOAP) en semantiek. Ook bepaalt de API het technische communicatieprotocol dat gehanteerd wordt.

Een WEBAPI is een API die via webstandaarden (http, https) aangeroepen wordt. 

De API bepaalt de modaliteiten van de service aanroep, dus hoe een service wordt opgeroepen. De service zelf is een elektronische “dienst” die geleverd wordt, bijv. een bancaire transactie, het ophalen van klantengegevens, het aanmaken van een contract, enz…  

In de huidige software architectuur probeert men de interne details van de verwerking, die nodig is om de service te leveren, verborgen te houden voor diegene die de service gebruikt om op die manier een zeker isolatie te realiseren.  De service gebruiker moet enkel rekening te houden met de API (specificatie van de service aanroep) en niet met de interne implementatie. Men spreekt daarbij over “information hiding” en “encapsulatie”, begrippen die eigen zijn aan een “service georiënteerde architectuur”. Het werken met API’s refereert dus ook aan het gebruik van een service georiënteerde architectuur. In een service georiënteerde architectuur streeft men ernaar om de software services zeer nauw te laten aansluiten op de eigenlijke “business” services.

In de voorbeelden van services in vorige paragraaf, erkent men meteen de business service die geleverd wordt:  de software dienst “aanmaak contract” mapt 1-op-1 met de business dienst “aanmaak contract”.

Om de isolatie verder door te voeren, heeft de API vaak betrekking op een “service proxy”. De service proxy is een service die zichtbaar is voor de buitenwereld. De API naar de service proxy evolueert niet, of heel traag. De service proxy zelf roept de eigenlijke “back end” service aan, eventueel na het uitvoeren van conversies. De back-end dienst en de API van deze back-end dienst mag in de loop van de tijd veranderen, maar de proxy, die zichtbaar is naar de buitenwereld, blijft onveranderd. Ook dat is een vorm van encapsulatie die men nastreeft in een modern software ontwerp.

API’s zijn een de-facto standaard geworden voor het beschikbaar maken van data en business logica (transacties). API’s nemen hierbij de rol van (SOAP) web services over en gaan veel verder.

De samenwerking tussen applicaties binnen de organisatie, maar ook met applicaties van andere organisaties, steunt meer en meer op API’s. Ook de integratie met SAAS-diensten, denk bijvoorbeeld aan SalesForce, steunt in grote mate op API’s. Via de API worden de services van andere organisaties aangeroepen,  die informatie leveren, of die bepaalde transacties uitvoeren in realtime.

Het aanbieden van services via API's stelt andere organisatie in staat om de services van één of meer organisaties te combineren in zogenaamde composite applicaties.
Een voorbeeld:

• Een bank biedt services (API's) aan om een autolening te berekenen, en om de lening aan te gaan;
• Een autoconstructeur biedt services (API's) aan om de voorraad aan stockwagens te raadplegen, en om een wagen aan te kopen;
• Een verzekeraar biedt services (API's) aan om een polis te berekenen en aan te gaan;
• Nu bouwt een andere onderneming een composite applicatie die toelaat om beschikbare stockwagens aan te kopen, inclusief lening en autoverzekering. Deze steunt op het aanroepen van de services (API's) van de drie bedrijven.

Een tweede voorbeeld:

• De overheid biedt services voor het inschatten van het rendement van zonnepanelen op het dak van de woning;
• Een bank biedt services (APIs) aan om een lening te berekenen, en om de lening aan te gaan;
• Nu bouwt een ondernemening die zonnepanelen plaatst een composite applicatie die toelaat om de business case te berekenen op basis van de eigen plaatsingsdiensten, een financiering aan te gaan bij een bank en een bestelling te plaatsen voor de installatie. Deze steunt op het aanroepen van de services van de overheid, de eigen services en die van de bank.  Deze composite app kan gebouwd worden als een mobile app, die de berekening kan uitvoeren op locatie, bijvoorbeeld bij het bezichtigen van de woning.

Deze voorbeelden illustreren ook dat de diensten van de overheid niet (enkel) aangeboden worden via de website van de overheid, maar via API’s, zodat zij kunnen opgenomen worden, in een bedrijfsproces en bedrijfsdiensten van andere organisaties die op die manier zelf diensten met toegevoegde waarde kunnen creëren.

Vandaag zijn er in de wereld 2,7 miljard gebruikers van een smartphone. Ruim 60% van deze populatie raadpleegt het internet via de smartphone.  Daarnaast zijn er 1,3 miljard PC's, een aantal dat daalt. Uit deze cijfers blijkt duidelijk de noodzaak om informatie en applicaties te ontsluiten via mobiele toestellen,  ‘mobile first’ dus.

Mobiele toestellen hanteren een user interface die steunt op 'mobile Apps':  kleine, handige mini-applicaties die gericht zijn op één gespecialiseerd doel, bijvoorbeeld bancaire transacties,  sociale media, mail, media, reisinformatie, navigatie, enz… API’s zijn de lingua franca voor de communicatie vanuit deze mobile Apps naar de achterliggende (“back-end”) systemen. 

Bij de ontwikkeling van mobile Apps, hoort dus ook de ontwikkeling van de services (API’s) waarmee de apps zullen communiceren met de back-end;  

Belangrijk vertrekpunt bij API-ontwerp is dat meerdere varianten van API’s ondersteund kunnen worden. API’s komen in verschillende maten en gewichten. En één zo’n variant kan zich specifiek richten op mobiele toepassingen. Het specifieke karakter van API’s die gericht zijn op mobile apps, is dat ze een snelle interactie en opbouw van de schermen toelaten. 

Om specifieke mogelijkheden en data van een mobiel apparaat – bvb. camera of GPS – te gebruiken, dient een 'native' mobile App ontwikkeld te worden, bijvoorbeeld om barcodes te scannen, of de actuele geografische positie te kennen. Indien dit niet nodig is, kan een hybride mobiele toepassing volstaan. Zo’n hybride mobiele toepassingen gebruikt veel web technologie (HTML5, CSS, Javascript), waarna ze wel verpakt wordt tot een mobiele toepassing. Dergelijke hybride toepassing is veelal eenvoudiger en goedkoper.

Organisaties en bedrijven staan niet alleen in de wereld. Voor sommige maatschappelijke en commerciële uitdagingen wenst men samen te werken met andere organisaties of bedrijven, die dan partners worden. Alleen is het niet altijd gemakkelijk om die organisaties of bedrijven te identificeren en om de samenwerking op te zetten.  IT kan daarbij helpen.

Door het aanbieden van bepaalde elektronische services (API’s) naar externe partijen, worden andere organisaties en bedrijven uitgenodigd om van die services gebruik te maken.

API's zijn daar bij uitstek voor geschikt, omdat zij laagdrempelige ontwerprincipes hanteren zoals: eenvoud, snel te begrijpen en aan te roepen, weinig ontwikkeling nodig, aansluiting die geautomatiseerd kan gebeuren 24/7,  enz …

Enkele voorbeelden

Het gaat bijvoorbeeld om services van een verdeler waarbij die services betrekking hebben op de verkoop en distributie van consumentenproducten, denk aan Amazon.com.  Die services laten toe dat de andere organisaties hun producten of diensten via de verdeler kunnen commercialiseren naar consumenten;

Of het gaat bijvoorbeeld om services (API's) van een bedrijf die betrekking hebben op een elektronische geldbeurs voor consumenten, waarbij commerciële ketens kunnen aansluiten zodat zij betalingen aanvaarden via de geldbeurs, denk aan Google Pay. Vaak zijn er bijkomende services op vlak van productpromoties, klantenbinding (getrouwheidskaart), enz…

In beide voorbeelden ontstaat het ecosysteem van partners, op basis van een set van elektronische diensten die via API’s aangeboden worden aan de wijde wereld en waarbij partners snel en eenvoudig kunnen instappen op de elektronische diensten. API’s zijn eenvoudig en gemakkelijk te implementeren, ook door kleinere bedrijven of organisaties en bieden een open en laagdrempelige manier om deze organisaties of bedrijven te laten instappen in een ecosysteem.  Het bedrijf of de organisatie die de API’s aanbiedt, bouwt op die manier een volledig ecosysteem van partner organisaties die samen een toegevoegde waarde leveren naar de eindklant.

Sociale media zoals Twitter, Facebook, Instagram, Youtube, Snapchat vormen vandaag het meest populaire, het meest aangewezen kanaal om vanuit de overheid boodschappen naar het grote publiek te brengen, en ook om met het publiek te interageren over allerlei thema’s.

Hierdoor wordt het mogelijk om trends op sociale media waar te nemen, opinies en feedback te bekomen over bepaalde dienstverlening door de overheid. En ook actief informatie te publiceren en delen m.b.v. geautomatiseerde processen.

De manier waarop dit gebeurt, is via API's. Er is een brede waaier aan integratie API’s voor het consulteren, analyseren maar ook voor het geautomatiseerd publiceren.

Er zijn ook diverse spelers die zich als tussenstation opwerpen: er zijn diensten voor het beheer en analyse van sociale media.  Ook deze beheer en analyse services worden weerom ontsloten door …. jawel API’s.

In de wereld van 'Internet of Things' wordt het Internet doorgetrokken naar fysieke apparaten (van graafmachine tot fontein), publieke infrastructuur (verkeerslichten, ANPR-camera’s, meters van waterstanden, water- en luchtkwaliteit, …) en alledaagse gebruiksvoorwerpen (wagen, domotica, alarmsystemen, verlichting, huishoudelijke toestellen, wearables, het weegtoestel in de badkamer, slimme camera’s, Alexa, Siri, de slimme energiemeter, enz.).

De consequenties van deze IoT-wereld kunnen moeilijk onderschat worden. Heel wat bestaande bedrijfsprocessen zullen erdoor geïmpacteerd worden en er zullen heel wat nieuwe diensten ontstaan.

IoT steunt volop op API’s. API’s worden gebruikt om het apparaat te laten communiceren met back-end systemen of omgekeerd, om de apparaten aan te sturen.

IoT-systemen leveren een schat aan (nieuwe) informatie op, denken we aan de ANPR camera’s, de slimme wagens, de slimme energiemeter, op basis waarvan nieuwe diensten kunnen gebouwd worden, zoals op vlak van mobiliteit, veiligheid, energiebeheer enz… .  

Via API’s wordt deze informatie ter beschikking gesteld, soms ook in realtime, zodat er interactieve systemen kunnen gebouwd worden, zoals op vlak van verkeersgeleiding, beveiliging,  aansturing van huishoudtoestellen, enz… . De verzamelde informatie vormt uiteraard ook een nieuwe en belangrijke informatiebron voor statistisch onderzoek in het kader van beleidsbepaling.

Open data worden in allerlei formaten aangeboden. Het ontsluiten van open data mbv. API’s biedt een aantal voordelen:

• informatie kan  gefilterd worden,
• zeer grote data sets kunnen op een efficiënte manier ontsloten worden, er is geen nood om de data eerst volledig te downloaden.
• en vooral: data sets kunnen met behulp van de API’s rechtstreeks in client toepassingen (mobile, hybride, web) geïntegreerd worden.

Bij API’s kan de applicatie ontwikkelaar worden geregistreerd en een API key toegekend worden aan elke client toepassing. Hierdoor kunnen meetgegevens omtrent het gebruik van de API’s door de diverse client toepassingen worden verzameld door het API Management platform. Meetgegevens die inzage geven naar de aanbieder van de Open Data omtrent het gebruik van de Open API’s.

Tip: doe een frequente check welke informatie als open data een toegevoegde waarde kan bieden naar partners, lokale besturen, bedrijven, burgers of anderen. Overweeg zeker het gebruik van API’s om de open data vervolgens ter beschikking te stellen.

Het Facilitair Bedrijf biedt een API management platformdienst aan. Voor deze platformdienst worden geen kosten aangerekend. Deze platformdienst omvat ook de operationele support van het platform.

De API Service Provider treedt op als financieel beheerder voor projectmatige uitbreidingen. De API Service Provider is verantwoordelijk voor ontsluiten van zijn API’s en dus het configureren van het platform wat betreft API proxies, omgeving (environment), “producten”, client applicaties etc.

HB-plus kent een aantal standaard aanvragen waarvan de eerste 3 verplicht afgenomen worden bij nieuwe aansluitingen.

• Services voor discovery van API metadata:                     24/7
• Services voor beveiliging van de API’s (API gateway,…):    24/7
• Services voor beheer van de API life cycle:                     24/7
• Services voor het bewaken en verbeteren van de business meerwaarde: 24/7

• Services voor discovery van API metadata:                  24/7  99,5%
• Services voor beveiliging van de API’s (API gateway,…): 24/7 99,7%
• Services voor beheer van de API life cycle:                   24/7   99,5%
• Services voor het bewaken en verbeteren van de business meerwaarde: 24/7 99,5%

Het Facilitair Bedrijf maakt gebruik van Amazon Web Services als platform om de doelstellingen van het programma 'datadriven facilitair management' te ondersteunen. Het API Management platform maakt deel uit van de standaardoplossing voor de communicatie tussen AWS-componenten en de componenten binnen het netwerk van de Vlaamse overheid.

De applicaties Databank Hoger Onderwijs en Leerdoelstellingen van AHOVOKS steunen elk op een webapplicatie die via het API Management Platform communiceert met de back-end diensten.

.

VITALINK van Agentschap Zorg & Gezondheid: de webapp MyHealthViewer toont de medische gegevens van een persoon en communiceert daartoe via het API Management Platform met de back-end diensten van Vitalink. Binnen deze toepassing wordt ook een mobiele sterke authenticatie toegepast. Deze webapp mikt op de doelgroep van 6 miljoen Vlamingen.