REST API’s worden vaak gepositioneerd als een vorm van simplificatie, lees ook onze eerdere blog simplification is a hoax. De granulariteit/scope van services wordt kleiner gemaakt en de Orkestratie komt bij de afnemers van onze REST API te liggen. Maar hoe weten je afnemers welke stappen zij in de orkestratie moeten doorlopen en ruimen ze de rommel van half uitgevoerde transacties op?
-
een voorbeeld uit de praktijk
Er komt een informatieverzoek binnen voor de aanschaf van een van onze producten, het betreft potentieel een nieuwe klant. Dat is uiteraard uitstekend nieuws.
In de bestaande situatie wordt alle informatie die beschikbaar is door onze portal of APP of een externe partij op onze service aangeboden en door ons in samenhang verwerkt. We ontzorgen onze afnemer en dragen zelf zorg voor de data integriteit.
Als we nu overstappen op een REST aanpak en daarmee de granulariteit van de services aanpassen naar een “resource” niveau ziet het plaatje er iets anders uit. Rest services gaan uit van collecties van resources bijvoorbeeld collectie: ”klanten” | resource: “klant”
De verantwoordelijkheid van de orkestratie wordt verlegd naar de afnemer.
Worstel je met een specifiek integratievraagstuk? Of heb je een vraag over bepaalde systemen, applicaties of Integration as a Service?
-
DE GEVOLGEN VOOR PROVIDER EN AFNEMER VAN DE SERVICES
- Als provider van de service hebben we zeker gesimplificeerd, alle complexe logica in de service is verplaatst naar de afnemer. De REST services zijn veel generieker opgezet en daardoor ook bruikbaar voor andere processen buiten de scope van “informatie verzoek aanschaf nieuw product”. Maar ook voor ons als provider van de services zijn er risico’s verbonden aan deze aanpak. We zullen soms matregelen moeten nemen om de “rommel” van een half afgerond proces op te ruimen en zo de dat integriteit te bewaken.
Voor de afnemer van onze service zijn er aanpassingen nodig in de manier van werken, de orkestratie moet worden ingebouwd. -
WELKE OPTIES HEBBEN WE?
Recept voor afnemer
REST service documentatie bevat standaard veel informatie over de resources en de collecties maar informatie over de orkestratie is niet standaard. Idealiter zorgt de provider van de service voor een “recept” voor de orkestratie in de vorm van documentatie.
1. Kijk of klant bestaat (ga verder bij stap 3)
2. Zoek een case bij de klant (bestaat de case niet ga verder bij 4 anders stap 5)
3. Maak een klant aan
4. Maak een case aan
5. Maak een taak aan “klant bellen”
Orkestratie service
Een andere oplossing is om bovenop de REST endpoint's toch een orkestratie laag te creëren, de afnemer dumpt zijn data en wordt ontzorgd maar je hebt eigenlijk niet veel bereikt ten opzichte van de bestaande situatie.
Choreografie (eventbus)
De eventbus is natuurlijk geen RESTfull oplossing, maar je kan er wel voor kiezen om dit in te zetten naast je REST API’s om deze usecase mee in te vullen. Houd de WeAreFrank blogs goed in de gaten voor een uitgebreide uitleg over dit onderwerp
EEN GOEDE KEUZE MAKEN
Als je overweegt om je integratie landschap naar REST architectuur om te zetten neem dan contact op met WeAreFrank! om je te helpen met het vermeiden van de valkuilen die deze verandering met zich mee zal brengen,
Wil je meer weten over hoe je een REST API bouwt, test en beheert met ons Frank!Framework? Bekijk dan onze how-to video.
