In het vorige artikel hebben we de algemene onderwerpen rond API’s en hun geschiedenis besproken. Nu je op de hoogte bent van API’s, is het tijd om te begrijpen hoe ze zijn opgebouwd. Voor dit artikel zullen we Talend software gebruiken om je te laten zien hoe je API’s kunt ontwikkelen. Naast de ontwikkeling met Talend zul je ook zien hoe je automatisch documentatie over je API’s kunt genereren.
Talend API Designer
API-ontwikkeling is zo’n brede term omdat API’s in honderden toepassingen en/of programmeertalen kunnen worden ontwikkeld. Gelukkig heeft Talend een geweldige manier om uw eerste stap in het ontwikkelingsproces te zetten. Ze noemen het de API Designer, en dit zou je uitgangspunt moeten zijn bij het ontwikkelen van API’s met Talend.
In de API Designer kunt u het raamwerk van uw API in een grafische gebruikersinterface configureren. Dit is een webapplicatie die in uw Talend Cloud-omgeving draait. Een van de grote voordelen hiervan is dat je het raamwerk kunt delen met iedereen in je Talend Cloud-omgeving, zodat zij kunnen zien waar je mee bezig bent. Voor CI/CD-doeleinden kunt u een Git-repository toevoegen en uw API-definities opslaan in een van de volgende formaten:
- OAS 3.0
- OAS/Swagger 2.0
- RAML 1.0
Deze standaardformaten bevatten alle informatie die u configureert voor uw API en alle eindpunten ervan. Laten we zeggen dat u bijvoorbeeld wilt dat consumenten toegang krijgen tot productgegevens, u kunt een product-API maken met meerdere eindpunten zoals een GET-eindpunt om producten te tonen en een POST-eindpunt dat een nieuw product in de database creëert. Dingen zoals wat voor soort Query Parameters een gebruiker kan geven bij het verzenden van een verzoek worden ook opgeslagen in dat standaard formaat. Informatie zoals welke Query Parameters verplicht zijn komt goed van pas wanneer u de documentatie publiceert, omdat dit de consument van de API een duidelijk beeld geeft van de parameters die zijn toegestaan voor uw API. Bijvoorbeeld: u heeft een API-documentatiepagina waar een consument kan lezen over het doel van een bepaalde API en ook over het gebruik ervan, belangrijke informatie zoals het URI-path of de parameters die nodig zijn.
Talend API Tester
Een andere mooie functie die ook verbonden is met de API Designer is de API Tester. Deze heeft vergelijkbare functies zoals bijvoorbeeld Postman, waar je je API kunt testen door verzoeken naar die API te sturen en de resultaten te onderzoeken. De API Tester heeft zelfs een Maven plugin waar je testen kunt automatiseren vanuit je command line interface door het genereren van standaard JUnit/Surefire rapporten en stelt je in staat om aangepaste URL’s te configureren die voor en/of na een test worden geinformeerd.
Talend Studio
Nadat het API-raamwerk goed is geconfigureerd, kunt u naar de Talend Studio gaan om de API-aanvraag en -respons met al zijn logica en functionaliteiten te ontwikkelen. Het mooie hiervan is dat u het raamwerk eenvoudig kunt gebruiken door de API-configuratie uit de cloud te laden en vervolgens eenvoudigweg binnen de studio op uw doek te slepen. Dit laadt automatisch de gehele configuratie die je hebt gemaakt in de API Designer.
Op basis van het verzoek dat de consument stuurt, kunt u kiezen uit honderden componenten om het verzoek af te handelen. Zo kunt u bijvoorbeeld een Java-component gebruiken om dynamisch een SQL-query te bouwen op basis van het verzoek en die query vervolgens gebruiken om data uit een Snowflake Data Vault te halen. Natuurlijk kunt u elke andere bron gebruiken om de data op te halen die in het API-respons aan de consument wordt geretourneerd.
Als je klaar bent met het ontwikkelen van alle logica die nodig is, kunt u verder gaan door de respons component binnen de studio te configureren. Hiermee kunt u configureren wat voor soort antwoord u terugstuurt naar de serviceconsument, bijvoorbeeld in een JSON- of XML-formaat. Verder kunt u ook de antwoordkoppen in dat component instellen. Sommige veelgebruikte responskoppen zijn:
- HTTP Method
- Versie
- Content-Type
- Status code
- En meer…
Dus nu je de API-job in de studio hebt voltooid is het tijd om te testen of het werkt. Het fijne aan de studio is dat je de API niet hoeft te publiceren en uit te rollen om het te testen.Je kunt de job eenvoudig binnen de studio uitvoeren, en de API zal beschikbaar zijn via de localhost. Op deze manier kunt u snel de functionaliteit van de API testen en zien of deze voldoet aan de eisen. Een van de dingen die kan opduiken is de performance van de API, omdat het tijd kan kosten om een grote aanvraag af te ronden wanneer deze veel records retourneert. Een goede oplossing om te overwegen is om je respons te pagineren, waardoor de consument kan bepalen welk deel van de respons moet worden geretourneerd en dit verlaagt de druk op je API-prestatie.
In de volgende uitgave van de API Services serie gaan we behandelen hoe AWS wordt gebruikt om de API’s in de cloud te implementeren en te laten draaien, dus blijf op de hoogte!
Ben je geïnteresseerd om de ontwikkeling van API’s in actie te zien? We geven je graag een live demo en beantwoorden al je vragen. Neem gerust contact met ons op voor meer informatie.
Contact