Ontdek de link tussen integratietechnieken en de lagen van een applicatie

In het eerste deel van onze reeks over integratiemogelijkheden kwamen verschillende vormen van integraties zoals API’s, widgets en URL’s aan bod. Met elk van deze vormen kun je dezelfde functies aanbieden zoals een betaling doen, iets te koop aanbieden, enz. Eén ding hebben ze allemaal gemeen. De ene partij biedt een functie aan zodat de andere partij deze kan gebruiken. Afhankelijk van welke verantwoordelijkheid elke partner wil nemen, kies je voor een andere integratievorm. Deze keer gaan we een stap verder. We verdiepen ons in het principe van een gelaagde architectuur. Dit passen we toe bij zeer veel applicaties. We verdelen de verantwoordelijkheden van een applicatie over verschillende ‘lagen’ die met elkaar verbonden zijn.

Het meest courante type, de API, biedt enkel de business logica aan. De persoon die de API maakt en aanbiedt, is de API-producer. De API-consumer is de partner die de API gebruikt en ter beschikking stelt van zijn klanten.

Bij API’s is het de verantwoordelijkheid van de API-consumer om zelf de nodige stappen te zetten om deze om te vormen naar een scherm voor zijn gebruiker. Dit houdt in dat de partner die de API ter beschikking stelt van zijn gebruikers zelf de presentatielaag maakt.

De scheidingslijn tussen consumer en producer voor deze integratie is beschreven in het API-contract of de swagger. Deze beschrijft concreet waar de verantwoordelijkheid van de consumer eindigt en waar die van de producer begint.

Zo een technisch contract of de swagger is geschreven in een specifiek formaat. Hierin staat wat de API nodig heeft als informatie om zijn ding te doen en welke info je mag verwachten als antwoord. De swagger beschrijft enkel de vorm waarin de informatie terugkomt, niet hoe de achterliggende businesslogica in elkaar zit of hoe het gedrag wordt omschreven.

Het grote voordeel is dat jij als consumer van de API zelf de verantwoordelijkheid houdt over de presentatielaag: jij kiest wat jouw klant ziet, wat hij moet doen of niet om de service te gebruiken. Het correct invullen van de API zoals omschreven in de swagger is de verantwoordelijkheid van de consumer. De producer van de API is verplicht om gepast te reageren op de aanvraag van de consumer. Ook de verdere verantwoordelijkheid over de datalaag ligt bij de producer.
 

Zo een contract lijkt simpel. Maar op de scheidingslijn van verantwoordelijkheden zit wel wat marge voor misinterpretatie. De swagger omschrijft wat je aan de API’s kunt vragen en wat hij kan teruggeven maar niet het ‘gedrag van de API’.

Stel nu een lening-simulatie API. Deze vraagt 2 velden: het bedrag van de aankoop en de eigen inbreng. De swagger gaat niet omschrijven hoe de API reageert als de eigen inbreng hoger is dan het bedrag van de aankoop of als één van de 2 getallen negatief is. Er staat wel in wat je terugkrijgt van de API: je kunt de lening al dan niet krijgen.

Wil je meer weten over het gedrag van de API? Deze onderliggende businessregels vind je terug in de documentatie van de API. Het voorbeeld met de leningsimulatie is erg eenvoudig. Maar als we met complexere API’s werken waar bijvoorbeeld ook opgeslagen data invloed hebben op het resultaat van een API, dan wordt dit gedrag potentieel heel uitgebreid.

Wat de API teruggeeft aan de consumer noemen we het externe gedrag van de API. Het interne gedrag staat beschreven in de documentatie. Zo weet je als consumer van de API waarop je mag rekenen.

De Iframe, widget en SDK gaan we even op één hoop gooien. Al deze integraties gaan een stap verder dan de businesslogicalaag en bieden ook een grafische interface. Deze interface kan worden ‘ingesloten’ in de interface van de consumer en zo versnelt het implementatieproces aanzienlijk. De grafische interface ondersteunt in de meeste gevallen ook de interacties van de gebruiker en maakt zo deel uit van de presentatielaag.

De verantwoordelijkheden tussen producer en consumer liggen hier natuurlijk anders dan bij een API. Deze integratievormen hebben ook een contract, een manier waarop deze kunnen worden geïnitieerd door de software van de consumer. Daardoor zullen ze naast het aanbieden van een grafische schil ook een resultaat teruggeven aan deze software. Dit is heel overeenkomstig met de contracten van een API. Het grote verschil is nu net de grafische interface en wat deze juist doet. 

Wanneer dergelijke integratie wordt opgezet, verwacht de consumer dat deze bepaalde functies opneemt. Zo kun je bijvoorbeeld verwachten van een mapswidget dat je als gebruiker kunt inzoomen of een route tekent. Dit alles maakt onderdeel uit van het externe gedrag van een widget. De producer van de widget is hiervoor verantwoordelijk. Bij deze integratievormen heeft de producer dus de verantwoordelijkheid over de presentatielaag en de businesslaag. Het nadeel voor de consumer van deze integratievorm is dat deze niet meer kan bepalen hoe en wat de eindklant ziet.

Dergelijke implementaties hebben ook in meer of mindere mate een invloed op de omgeving waarin ze draaien. Deze impact ‘constant’ houden is iets waarmee de producer van de integratie rekening moet houden.

Belangrijk in de keuze van integratietypes is weten welke verantwoordelijkheid je wilt dragen en welke niet. Dit zowel in het bouwen als in het onderhouden van de integratie. Ook goed om te weten, is dat de data uiteindelijk altijd in de persistente laag zit en dus altijd bij de producer van de integratiemethode.