API-architectuur: governance, prestaties en integratie

Het idee van een application programming interface gaat terug tot de begindagen van de informatica. Wat veranderde, is het gewicht dat erop rust. Libraries en besturingssystemen stelden routines en protocollen bloot in de jaren zestig en zeventig. API's werden krachtiger in de jaren tachtig en negentig, en de komst van het publieke internet maakte er de manier van waarop systemen over organisatiegrenzen heen praten.

SOAP, en daarna REST, maakten dat gewoon. REST is vandaag de standaardkeuze voor het bouwen van webinterfaces omdat het eenvoudig is en zich makkelijk plooit. Precies dat gemak is waar de problemen beginnen.

Veelvoorkomende risico's in API-architecturen

We hebben jaren aan data-integratie besteed over B2B-platformen, SOA, ESB, message queuing, transformatie en API's. Dezelfde problemen komen terug.

Onbeheerde point-to-point-interfaces

Wanneer een API-landschap wordt gebouwd zonder beheertooling of controleproces, eindigen organisaties met duizenden API's waarvan het bestaan niet altijd bekend is en die niemand durft te wijzigen omdat de gevolgen onduidelijk zijn. Het aantal groeit, de duplicaten vermenigvuldigen zich, en parallelle API's doen bijna hetzelfde werk zonder dat iemand hun evolutie bestuurt.

Versies

API-beheer betekent jongleren met versies, elk met eigen gedrag en eigen compatibiliteitseisen. Oude versies in leven houden voor bestaande systemen is waar de kost zich opstapelt, en afhankelijkheden tussen versies creëren conflicten die pas laat opduiken.

Onderhoud

Een API onderhouden is niet alleen defecten herstellen. Het is nieuwe gebruikersbehoeften en nieuwe technologie volgen. Preventief onderhoud is wat de API veilig en snel houdt, en het vraagt middelen en planning die zelden waren begroot.

Afhankelijkheidslussen

Cyclische afhankelijkheden tussen API's creëren lussen waarin A B nodig heeft en B A. Debuggen en upgraden worden allebei moeilijk, en processen lopen vast op manieren die pijnlijk zijn om te diagnosticeren.

Volume en prestaties

Naarmate het gebruik groeit, wordt het aankunnen van het aanvraagvolume de beperking. Responstijden en verkeerspieken zijn waar het zichtbaar wordt. Ontwerpen voor dat volume zonder prestaties op te geven is een echt architectuurprobleem, geen tuningoefening.

Documentatie

Documentatie bepaalt of een API wordt gebruikt of omzeild. Verouderde of dunne documentatie levert implementatiefouten op en verlengt elk project dat ermee in aanraking komt.

Componenten van de doelarchitectuur

Wij mikken op een API-architectuur die actuele API-technologie gebruikt en er de lagen voor beheer, security en prestaties omheen zet. Zes componenten dragen dat.

Een systeem voor API-management

API's controleren en blootstellen zodat afnemers geïdentificeerd zijn en het gebruik gemeten wordt. Gebruik een beheerplatform om te monitoren, te beschermen, te verdelen en te analyseren. Het resultaat is betere security, echt zicht op het gebruik en een beheersbare levenscyclus. Goed uitgevoerd laat het u ook toe het gebruik te verzilveren en partnerrelaties op feiten te voeren.

Een SOA-laag voor publicatie

Ontkoppel het gebruik van API's van de databronnen erachter, met een tussenlaag tussen de API's en de applicaties. U wint aan modulariteit, aan eenvoudiger onderhoud en aan herbruikbare services.

Datavirtualisatie

Geef toegang tot de informatie die nodig is, met respect voor regelgeving, securityregels en de omgang met gevoelige data. Virtualisatie maakt extraheren en dupliceren overbodig. Opslag- en verwerkingskosten dalen, vertrouwelijkheidsverplichtingen worden nagekomen, en de toegang verbetert. Het haalt ook de reflex weg om voor elke interne kortetermijnbehoefte een API te schrijven.

Tooling voor B2B-communicatie

Verplaats data veilig en efficiënt over de protocollen die partners wereldwijd effectief gebruiken, zonder in te boeten aan doorvoer. Betere datasecurity, betere verwerking van transactievolumes, meer interoperabiliteit.

Mapping- en transformatietools

Haal de complexiteit van dataverwerking uit de API zelf en leg ze in tools die daarvoor gebouwd zijn. De prestaties van de API verbeteren, de complexiteit daalt, en de integratie wordt makkelijker te onderhouden.

Een proces voor het maken van API's

Bepaal hoe een API wordt gemaakt en onderhouden voor het landschap groeit. Dat is wat het overmatige gebruik en de duplicatie tegenhoudt, en het verlaagt de ontwikkelkost door het werk te voorkomen in plaats van het achteraf op te ruimen.

Kort samengevat

Onze aanpak combineert API-management, een SOA-laag, datavirtualisatie, B2B-communicatie, echte transformatietooling en een vastgelegd ontwikkelproces. Samen beantwoorden ze wat de business nu nodig heeft en laten ze ruimte voor wat ze straks nodig heeft, en dat is het deel dat een architectuur op API's alleen nooit opvangt.