Je hoort programmeurs wel eens over API’s of “Aapies” praten. Een term die veel wordt gebruikt in ons vakgebied, maar wat is het en wat doet het precies? Er zijn verschillende soorten API’s die hun eigen voor en nadelen hebben. In dit artikel komt de API dus uit de mouw!

Wat is een API (Aapie)?

Bij dit woord denk je misschien snel aan een aap in de dierentuin, maar daar heeft een API niks mee te maken. API staat voor Application Programming Interface en is een kapstok term. Een API wordt vooral gebruikt om 2 stukken software met elkaar te laten communiceren. Dit zorgt ervoor dat automatiseren makkelijk en goedkoper kan. Je zou bijvoorbeeld je webshop met je voorraadsysteem kunnen laten praten, en zoals je misschien kan voorstellen heb je hier veel mogelijkheden mee!

Verschillende soorten API’s

API’s zijn er in vele soorten, dat noemen we ook wel architecturen. Elke architectuur heeft zijn eigen voor- en nadelen. In deze blog bespreek ik de drie meest populaire architecturen:

  • SOAP: een API architectuur ontwikkeld door microsoft in 1998. Deze gebruikt XML voor hun data. Dit data format bestaat al een tijdje en heeft dus een stevige basis en is daardoor ook betrouwbaar.
  • REST: Dit is het meest gebruikte architectuur op het web momenteel. Deze gebruikt vooral JSON data format maar ondersteunt ook andere data types.
  • GraphQL: een API architectuur ontwikkeld door Facebook in 2013 en in 2015 in gebruik genomen. Deze architect is vooral makkelijker te gebruiken en leesbaarder. Deze maakt overigens ook gebruik van het JSON data format

Welke API architectuur kies je?

Om je een idee te geven waarom programmeurs voor een bepaalde architectuur kiezen vergelijk ik de bovengenoemden met elkaar op het gebied van snelheid, betrouwbaarheid, ontwikkelen en documentatie. 

REST vs SOAP

Snelheid

Het grootste verschil tussen REST en SOAP API’s zit in het soort data dat ze gebruiken. SOAP API’s gebruiken voornamelijk XML, terwijl REST JSON gebruikt. XML is wat ouder en ook meer verbose (verbose betekent dat alles tot in het kleinste detail wordt uitgelegd of gedocumenteerd). Hierdoor zijn de aanvragen groter en dus ook trager. REST aanvragen zijn te cachen, waardoor ze een stuk sneller zijn. Het komt er dus op neer dat SOAP API’s een stuk trager zijn, wat tegenwoordig echt killing is voor een webapplicatie. Vandaar dat mensen vaker voor REST dan SOAP kiezen. 

Betrouwbaarheid

Hier steelt SOAP duidelijk de show. SOAP heeft naast SSL nog veel meer tools om hun API’s betrouwbaar te maken en te houden. Ook hoeft SOAP niet perse over het internet te gaan. Vandaar dat grote organisaties, zoals banken, SOAP boven REST verkiezen. REST is heus wel betrouwbaar, maar SOAP blinkt hier simpelweg in uit.

Ontwikkelen

Belangrijk punt voor beide systemen en beide hebben hun eigen voor- en nadelen. SOAP is namelijk wat ingewikkeld, maar heel strikt waardoor fouten minder vaak voorkomen. Het nadeel is echter dat de ontwikkeling dan ook langer duurt en duurder is. REST kun je een stuk makkelijker en sneller ontwikkelen en geeft je ook nog eens meer vrijheid. Zowel een voordeel als nadeel, want hoewel je sneller er vrijer kunt werken, is de kans op een foutje groter.

Documentatie

Hier heeft SOAP een hele efficiënte oplossing voor gevonden. Ontwikkel je met SOAP, dan maak je ook direct een bestand dat dient als documentatie. REST geeft je dit als optie en verplicht het niet. Omdat je tijdens het ontwikkelen met SOAP altijd je documentatie hebt, maak je het een stuk makkelijk om een derde partij met jouw API te laten communiceren.

Conclusie

Om een keuze te maken tussen REST en SOAP moet je jezelf de afvragen waar jij het meeste waarde aan hecht. Gaat jouw voorkeur uit naar snelheid? Dan is REST de juiste optie. Heb je liever een systeem dat uitblinkt in betrouwbaarheid? Kies dan voor SOAP.

REST vs GraphQL 

Snelheid 

Hier is GraphQL voor gemaakt! REST was wel een vebetering op de verboseheid van SOAP, maar REST stuurt data mee die je niet per se nodig hebt. Onnodig grote aanvragen die de snelheid belemmeren dus. Ook ben je met GraphQL in staat om met één aanvraag alle data op te halen, terwijl bij REST soms meerdere nodig zijn. GraphQL kan je niet cachen terwijl bij REST soms meerdere nodig zijn., dat is wellicht een klein nadeel.

Dit komt omdat nieuw is er niet voor zijn al zijn hier partijen wel mee bezig dus verwacht ik hier snel verandering in

Betrouwbaarheid

GraphQL bestaat nog maar kort en heeft dus wat minder tried en testen. Voor GraphQL en REST gelden verder dezelfde veiligheidsmaatregelen. Je zou dus kunnen stellen dat REST een iets betrouwbaarder is, al is het niet heel overtuigend. 

Ontwikkelen

GraphQL is ten opzichte van REST wat lastiger te ontwikkelen, maar geeft wel meer structuur. Je moet namelijk nadenken welke data je echt nodig hebt, waardoor je minder snel fouten maakt. REST is weliswaar makkelijker te ontwikkelen, maar door de vrijheid die je hebt sluipt een foutje er makkelijk in.

Documentatie

Punten voor GraphQL. Tijdens het ontwikkelen geen geef je namelijk wat de data is en waarvoor het is. Hierdoor kunnen mensen zonder documenten je API gebruiken omdat het zichzelf uitlegt. Bij REST hoeft dit niet en is dit een keuze. 

Conclusie

Met beide keuzes kun je goed uit de voeten, al duurt het ontwikkelen van een GraphQL API waarschijnlijk iets langer. Vraag jezelf ook al of je veel statische content hebt. Zo ja, dan is REST momenteel de betere keuze zijn, omdat je data kan cachen.

GraphQL vs SOAP

Snelheid

Alsof je een Formule1 auto tegen een Skoda Fabia laat racen. Het dataformat van GraphQL is zo superieur vergeleken met SOAP. Met GraphQL haal je namelijk alleen data op die je nodig hebt en laat je alle overige data achterwege. GraphQL is dus de onbetwiste winnaar wat betreft snelheid.

Betrouwbaarheid

Hier is SOAP de voorloper. SOAP heeft namelijk, naast SSL, nog meer tools om het gebruik van hun API veilig en betrouwbaar te maken. Ook hoeft SOAP niet perse over het internet te gaan. Grote bedrijven zoals banken kiezen daarom graag voor SOAP. GraphQL is ook een stuk jonger hierdoor kunnen er nog kinderziektes in zitten. Dit betekent niet dat GraphQL niet te vertrouwen is maar SOAP heeft hier wel een voorsprong. 

Ontwikkelen

GraphQL en SOAP zijn qua ontwikkeling vergelijkbaar. Beide hebben vaste structuren waardoor de kans op fouten klein is. Hier kunnen we dus geen winnaar kiezen.

Documentatie

Wederom een gelijke score! Bij beide architecturen moet je documentatie maken om de API werkend te krijgen. GraphQL is wellicht iets leesbaarder, maar dat heeft ook met voorkeur te maken.

Conclusie

Het lijkt erop dat GraphQL precies tussen SOAP en REST valt. Het is snel en heeft de handvatten die REST in sommige gevallen mist, maar SOAP heeft een betere veiligheid en betrouwbaarheid. Weer een kwestie van prioriteiten stellen dus. Ga na wat jij het belangrijkst vindt en maak op basis van jouw prioriteiten de keuze.

Welke API heb jij nodig?

Zoals je kunt lezen is het type API dus afhankelijk van je wensen en behoeftes. Heb jij behoefte aan snelheid? Betrouwbaarheid? Een vaste structuur? Duidelijke documentatie? Bespreek al jouw wensen met je ontwikkelaar, zo kan hij of zij jou het beste adviseren in de voor jou meest geschikte API architectuur.