BLOG

API First!

16 juni 2017

In de eerste blog van Sjaak las je al over Atlas, het nieuwe software platform waar we bij Voogd & Voogd sinds 2014 aan bouwen. Atlas is de backend, laten we zeggen 'de motor' van o.a. Klik & Advies. Sjaak noemde daarbij technieken als DDD en CQRS, waar we veel meer over kunnen (en zullen gaan) schrijven.

Zoals in de introductie al te lezen was, ontwikkelen we binnen Atlas alle software 'API First'. Dat wil zeggen dat we voor alle gewenste functionaliteit starten met het bouwen of uitbreiden van de benodigde API's. Na oplevering van deze API's wordt bijvoorbeeld Klik & Advies hierop aangesloten, zodat de functionaliteit beschikbaar wordt in de kantoormodule voor onze adviseurs. Omdat alle API's beschikbaar zijn in onze API store, is het ook voor partijen buiten Voogd & Voogd eenvoudig om hun systemen of webpagina's te koppelen aan ons platform.

'API First' is dus het motto... Wel zo gepast om mijn eerste blog dan ook aan API's te wijden. Maar wat is eigenlijk een API? Volgens Wikipedia: "Een application programming interface (API) is een verzameling definities op basis waarvan een computerprogramma kan communiceren met een ander programma of onderdeel (meestal in de vorm van bibliotheken)." Duidelijk? Niet echt? Of echt niet? Zie een API maar als de ingang van een applicatie. Andere applicaties of webpagina's kunnen gebruik maken van deze ingang, om informatie op te halen of te wijzigen.

Om er gelijk nog een term in te gooien; bij Voogd & Voogd bouwen we 'RESTful' API's. REST staat voor Representational State Transfer. Dat laatste mag je direct vergeten, maar onthoud dat in REST de 'resource' centraal staat. Elk stuk informatie wat je een naam kunt geven, kan een resource zijn. Een resource kan een fysiek object zijn (bijvoorbeeld een boek) of minder tastbaar (bijvoorbeeld een adres). Of meer in de verzekeringssfeer: een klant of een polis. De collectie van alle klanten is ook een resource. Een resource kan bestaan uit andere resources. Een klant kan bijvoorbeeld bestaan uit een adres en een collectie polissen.

In REST worden standaard HTTP methodes gebruikt om resources te creëren (POST), te wijzigen (PUT), op te halen (GET) en te verwijderen (DELETE). Ook de URL's waarop de resources worden benaderd, zijn volgens een patroon opgebouwd. Enkele voorbeelden:

POST /klanten - een klant creëren

GET /klanten - alle klanten ophalen
GET /klanten/123 - de klant met nummer 123 ophalen
GET /klanten/123/polissen - alle polissen van de klant 123 ophalen
GET /klanten/123/polissen/456 - de polis met nummer 456 van de klant 123 ophalen

PUT /klanten/123/adres - het adres van klant 123 wijzigen

DELETE /klanten/123 - klant 123 verwijderen

REST dwingt je om goed te bedenken wat de resources in jouw API zijn, en welke methodes daarbij horen; zonder dat het protocol je beperkt qua mogelijkheden. Een ideaal handvat! Door de combinatie van slim gekozen resources, bruikbare methodes en uniforme URL's, bouw je een herkenbare API. Gebruikers kunnen er direct mee uit de voeten, zonder al te veel kennis van - in dit geval - het verzekeringsdomein waarin de API zich bevindt.

De volgende keer beschrijf ik hoe ik onlangs het concept van een bonus/malus tabel (je weet wel, de tabel die de korting op de premie van een autoverzekering bepaalt) in een RESTful API heb geïntegreerd en hoe we die API vervolgens inzetten.

DEZE BLOG DELEN OP

© 2018 | Voogd & Voogd
Website powered by Dutch Media Lab