Alles over SOAP vs REST API 

In de wereld van applicatieprotocollen zijn SOAP en REST API’s geen vreemde termen. Maar wat houden deze protocollen nu precies in en in welke situatie heeft een REST API of een SOAP API de voorkeur? Lees hier alles over deze twee type API’s om een gegronde afweging te maken tussen SOAP vs REST API in jouw situatie én ontdek hoe je SOAP naar REST migreert in verschillende situaties.

Mask Group 1

Wat zijn SOAP en REST?

SOAP
SOAP (Simple Object Access Protocol) is een protocol ontwikkeld door Dave Winer, Don Box, Bob Atkinson en Mohsen Al-Ghosein in 1998, met als doel om gestructureerde informatie uit te wisselen tussen verschillende componenten.

REST
REST (Representational State Transfer) is een architectuurstijl, ontwikkeld door Roy Fielding in 2000 voor zijn proefschrift, waarmee software met andere software kan communiceren. REST API’s worden meestal gebruikt om HTTP-services te ontwikkelen.

SOAP vs REST API

Wat is nu precies het verschil tussen SOAP en REST API’s? Dat gaat voornamelijk om de manier waarop ze zijn opgebouwd én de manier waarop ze ze communiceren.

SOAP  is een protocol dat gebruik maakt van XML. API’s gebaseerd op dit protocol werken zodanig dat informatie in grote samengevoegde hoeveelheden over en weer worden gecommuniceerd. 

REST is een protocol dat daarentegen gebruik maakt van HTTP. Bij REST API’s wordt data in kleine stukjes gecommuniceerd. 

Systemen kunnen prima werken op basis beide soorten API’s, het lastige hierbij is alleen dat systemen gebaseerd op SOAP API’s geen data kunnen uitwisselen met systemen gebaseerd op REST API’s, en andersom. Dit komt dus simpelweg doordat de API’s op verschillende manieren data verwerken en communiceren.

Bekijk deze korte explainer en ontdek het precieze verschil tussen SOAP en REST API’s.

soap vs rest

Hoe pak je een migratie van SOAP naar REST API aan?

SOAP is een protocol dat al wat langer bestaat dan REST. Naarmate het internet zich ontwikkelde, ontstond de behoefte om lichtere applicaties te kunnen bouwen. Hierdoor werd REST onwikkeld, dat werkt op basis van HTTP in plaats van XML en dus voldeed aan deze wens. 

REST is tegenwoordig erg populair om webservices te koppelen vanwege de simpliciteit en daardoor gaan veel organisaties aan de slag met het vervangen van SOAP door REST.
Wil je ook jouw systemen die werken op basis van SOAP API migreren naar REST API? Dan doe je dit in drie stappen.

Stap 1: Begin met het opzetten van een migratieplan

Stap 2: Creëer een integratielaag als tussenstap om ervoor te zorgen                    dat alles in de tussenfase nog naar behoren blijft werken

Stap 3: Ga volledig over van SOAP API naar REST API

Rectangle 3

Is REST API echt eenvoudiger dan SOAP API?

Tegenwoordig werken de meeste nieuwe applicaties met REST API. Er wordt gesuggereerd dat orkestratie met REST namelijk simpeler werkt dan met SOAP. De granulariteit van services wordt namelijk kleiner gemaakt en de orkestratie komt bij de afnemers van de REST API te liggen.

De provider van een service op basis van REST heeft dus zeker gesimplificeerd, alle complexe logica in de service is namelijk verplaatst naar de afnemer. De REST services zijn veel generieker opgezet en daardoor ook bruikbaar voor meerdere processen. Aan de andere kant zijn er voor de afnemer van een service aanpassingen nodig in de manier van werken. De orkestratie moet namelijk worden ingebouwd.

 

BewerktWAF6

Een REST API zelf programmeren of opzetten a.d.h.v. een integration framework?

Heb je zelf een hoop technische kennis in huis en wil je een simpele REST API ontwikkelen? Dan kun je dit natuurlijk prima zelf programmeren. Wil je een REST-service aanbieden? Dan komt er een hoop bij kijken.

Je moet dan namelijk HTTP-calls kunnen versturenn én kunnen ontvangen, wat een stuk complexer is. Daarnaast moet je zelf alle randzaken goed inregelen, zoals OpenAPI-documentatie, security, message reliability en andere specificaties. Ook moet je zelf de code regelmatig controleren en aanpassen om ervoor te zorgen dat je oplossing veilig is en blijft. Uiteindelijk ben je ongeveer 90% van je tijd kwijt aan de technische realisatie en maar 10% met de functionaliteit.

Wanneer je een integratie framework gebruikt zoals het Frank!Framework, dan is de functionele flow losgekoppeld van de technische implementatie. Het framework is een totaalpakket waarin alle randzaken en technische details, zoals security, performance en documentatie, al geregeld zijn. Hierdoor kun je de focus leggen op het functionele deel van je service én is je service altijd veilig, omdat ook updates in het framework worden doorgevoerd.

5 best practices om een goede REST API te bouwen

Voor de beste prestatie van een REST API en optimaal gebruiksgemak zet je onderstaande vijf best practices in om een goede REST API te bouwen:

1. Bouw eerst een model van je data

2. Zorg dat je guaranteed delivery borgt

3. Gebruik zoveel mogelijk standaarden

4. Maak onderscheid tussen je afnemers

5. Zorg dat er nooit een actie in een URL komt te staan

Mainframe migraties, hoe pak je het aan

SOAP naar REST API voor grote Nederlandse verzekeringsmaatschappij

WeAreFrank! heeft een grote Nederlandse verzekeringsmaatschappij geholpen bij een complexe systeemintegratie. De verzekeringsmaatschappij koos er binnen deze systeemintegratie voor om in te zetten op simplificatie en migreerde een deel van de koppelingen van SOAP naar REST API's.

Wanneer we het hebben over simplificatie door REST, dan betekent dit dat je soms functionaliteit verliest. Daarnaast moet je rekening houden met de granulariteit van je data. In SOAP wordt bijvoorbeeld een klant met adresgegevens samen teruggegeven, terwijl je dat bij een REST API vaak uit elkaar haalt en een klant en adres als twee verschillende objecten ziet. Bij het omzetten van SOAP naar REST moet je er dus voor zorgen dat beide manieren van dataverwerking naast elkaar kunnen blijven bestaan. In het geval van deze verzekeringsmaatschappij gebruiken we
het Frank!Framework als een soort tussenlaag
om SOAP naar REST te vertalen en andersom.

Nederlandse verzekeringsmaatschappij

Benieuwd hoe WeAreFrank! een omvangrijke systeemintegratie succesvol afgerond heeft?

 

SOAP vs REST API bij gemeenten

Het vraagstuk SOAP vs REST is zeer relevant bij Nederlandse gemeenten sinds de invoering van Common Ground.

Over het algemeen werken bij gemeenten de taakapplicaties en het zaaksysteem volgens Zaak- en Documentservices (ZDS) API’s en zijn daarmee gebaseerd op SOAP. Conform Common Ground moeten de nieuwe taakapplicaties en zaaksystemen bestaan uit API’s voor Zaakgericht werken (ZGW) en dus gebaseerd worden op REST. Omdat systemen gebaseerd op SOAP en systemen gebaseerd op REST niet met elkaar kunnen communiceren, maakt het overgaan van SOAP naar REST een ingewikkelde klus. Je moet namelijk rekening houden met een “tussensituatie” waarbij niet alle applicaties kunnen communiceren met het zaaksysteem en vice versa. 

Om te kunnen bepalen wat de juiste aanvliegroute is voor een gemeente moeten er verschillende afwegingen gemaakt worden. Er kan gekozen worden tussen een viertal routes, namelijk:

1. Eerst het zaaksysteem vervangen
2. Eerst de taakapplicaties vervangen
3. Big bang: de taakapplicaties én het zaaksysteem tegelijk vervangen
4. Hybride: het zaaksysteem en een deel van de taakapplicaties vervangen

Eerst het zaaksysteem of eerst taakapplicaties vervangen?

In deze checklist lees je over de 4 manieren waarop je deze transitie kunt aanpakken en ontdek welke route het beste bij jouw gemeente past.

 

Van SOAP naar REST API voor gemeente Sittard-Geleen, Utrecht en Súdwest-Fryslân

Sinds Common Ground in het leven is geroepen ontkomt geen enkele Nederlandse gemeente eraan: de taakapplicaties en het zaaksysteem moeten over van SOAP API naar REST API.

Onze integratiespecialisten bij WeAreFrank hebben de gemeenten Sittard-Geleen, Utrecht en Súdwest-Fryslân op weg geholpen naar de nieuwe situatie conform Common Ground.

Ieder van deze gemeenten had een andere specifieke situatie. Zo maakte de gemeente Sittard- Geleen gebruik van een ESB (Enterprise Service Bus), een closed source oplossing. Dit was dus niet volgens de Common Ground-standaarden waarbij open source een vereiste is.

De gemeente Utrecht was op zoek naar een hybride oplossing voor het overgaan van hun SOAP-systemen naar REST API en de gemeente Súdwest-Fryslân had een Open Zaakbrug gerealiseerd om de systemen in SOAP en de systemen in REST met elkaar de laten communiceren.

Managed Integrations vs iPaaS-1

De Open Zaakbrug 2.0 helpt je als gemeente in de transitie van SOAP naar REST API

In dit document lees je hoe de Open Zaakbrug 2.0 ervoor zorgt dat jouw gemeente zorgeloos, veilig en vlekkeloos over kan gaan van SOAP (ZDS) naar REST API (ZGW).

Als gemeente over van SOAP naar REST API: waarom het inschakelen van een integratiepartner een verstandige keuze is.

Het is een monnikenwerk waar veel kennis en kunde bij komt kijken om al je systemen zonder problemen over te zetten van SOAP naar REST API. Een integratiepartner zorgt ervoor dat dit gehele proces in goede banen geleid wordt. Wij hebben de vier belangrijkste manieren waarop een integratiepartner je hierbij helpt op een rijtje gezet:

Manier 1: Een integratiepartner helpt je tot een efficiënte oplossing

Manier 2: Een integratiepartner helpt je bij het creëren van datavrijheid

Manier 3: Een integratiepartner is een consistente kennisbron

Manier 4: Een integratiepartner voorkomt dat je het wiel opnieuw moet uitvinden]

Gratis adviesgesprek inplannen om SOAP vs REST API te bespreken

Wil je graag meer weten over wat onze integratiespecialisten en ons Frank!Framework voor jouw organisatie kunnen betekenen in het vraagstuk rondom SOAP vs REST API? Plan dan gratis en vrijblijvend een (digitaal) adviesgesprek in met een van onze integratiespecialisten. We denken graag met je mee en verzorgen vrijblijvend een demo op maat.

adviesgesprek