REST eller SOAP i integrasjonene deres?
REST er den lette, HTTP- og JSON-baserte måten å bygge nye API-er på og er standard i dag. SOAP er en eldre, kontraktstung XML-protokoll som lever videre i systemer hos myndigheter og store virksomheter. Nye integrasjoner lages i REST, men eksisterende SOAP-tjenester kapsles som regel inn bak et moderne grensesnitt i stedet for å bygges om.
SOAP føles for mange som et ord fra en annen tid, og på en måte er det nettopp det. Men prøv å koble systemene deres sammen med en myndighet, en bank eller et etablert ERP-system, og sjansen er stor for at SOAP fortsatt sitter der. Spørsmålet er derfor sjelden «REST eller SOAP» på et blankt ark, men hvordan det moderne skal møte det som allerede finnes. Her er forskjellene og en strategi som holder.
Forskjellen i korte trekk
Både REST og SOAP er måter å la systemer utveksle data på, men de kommer fra ulike epoker og tenker forskjellig.
SOAP er en protokoll. Den sender meldinger som XML etter en streng, formell kontrakt som beskriver nøyaktig hvordan hvert kall skal se ut. Kontrakten er tung, men entydig, og SOAP har innebygde standarder for sikkerhet og pålitelighet. Protokollen ble laget for en verden av store bedriftssystemer som trengte formelle garantier.
REST er snarere en stil enn en protokoll. Den bruker nettets egne verb (hente, opprette, oppdatere, slette) direkte over HTTP og sender vanligvis lett JSON i stedet for tung XML. Den er nedstrippet, rask å komme i gang med og passer naturlig for nett og mobil. Der SOAP er formell og regeltung, er REST lett og pragmatisk.
Hvorfor nye API-er bygges i REST
Når noen bygger et nytt API i dag, er svaret nesten alltid REST, og grunnene er praktiske snarere enn ideologiske. REST er billigere å utvikle, lettere for nye utviklere å forstå og har en moden verktøykjede der det meste allerede er løst. JSON er lett å lese og veier lite over nettet, noe som har betydning for mobilapper.
SOAP krever mer: tyngre verktøy, mer struktur rundt hvert kall og en formalisme som sjelden betaler seg for en ny tjeneste. For alt som bygges fra bunnen av, er REST derfor standardvalget, og SOAP er i praksis noe man møter, ikke noe man velger.
Hvorfor SOAP-integrasjonene likevel består
Samtidig forsvinner ikke SOAP, og det finnes gode grunner til det. Store systemer byttes ikke ut fordi teknologien bak grensesnittene føles gammel. En SOAP-tjeneste som en myndighet, en bank eller en ERP-leverandør tilbyr, er ofte stabil, velprøvd og noe dere ikke rår over. Dere må integrere mot den slik den er.
Å bygge om en SOAP-integrasjon som fungerer, koster penger uten å gi noen ny verdi i seg selv. Den gjør allerede jobben sin. Derfor lever SOAP videre, ikke som et aktivt valg, men som en realitet i systemlandskapet. Det gjelder særlig offentlig sektor og etablert industri, der levetiden til systemer måles i tiår.
Poenget er at de nye delene deres ikke trenger å arve den byrden. Utfordringen er å la moderne og gammelt sameksistere uten at det gamle smitter over på alt annet.
Adapterstrategien: kapsle inn det gamle
Mønsteret som nesten alltid er riktig, kalles adapter, eller innkapsling. I stedet for å la de nye tjenestene deres snakke SOAP direkte bygger dere et lite mellomlag som gjør oversettelsen på ett sted.
Adapteren snakker SOAP med det gamle systemet på den ene siden og tilbyr et rent, moderne REST-grensesnitt på den andre. All kompleksiteten (den tunge XML-en, den formelle kontrakten, særegenhetene) kapsles inn der. Utviklerne deres bygger mot et moderne grensesnitt og trenger aldri å vite at det sitter en SOAP-tjeneste i bunnen.
Fordelene er flere:
- Kompleksiteten samles. SOAP-særegenhetene finnes på ett sted i stedet for å være smurt utover hver ny tjeneste.
- Det nye holdes rent. Nye apper og integrasjoner snakker bare moderne REST.
- Fremtidssikringen blir enklere. Byttes det gamle systemet ut en dag, holder det å endre adapteren, ikke alt som ligger bak den.
Et konkret scenario
La oss si at dere skal bygge en ny kundeportal som må hente data fra et ERP-system der det eneste grensesnittet er SOAP. Det er mulig å la portalens kode snakke SOAP direkte, men da spres XML-håndteringen gjennom hele appen, og den bindes tett til særegenhetene i ERP-systemet.
I stedet bygger dere en adapter. Den kaller SOAP-tjenesten i ERP-systemet, tar imot XML-svaret og oversetter det til ren JSON som portalen kan bruke. Portalen ser bare et ryddig REST-API. Skulle ERP-systemet senere byttes ut med et som har et moderne API, endrer dere adapteren og lar portalen være som den er. Det gamle og det nye lever side om side uten at det ene hindrer det andre.
Vi i Weapp bygger både nye REST-API-er og adapterne som knytter dem sammen med eldre systemer. Vil dere modernisere uten å kaste det som fungerer? Se tjenestene våre eller ta kontakt.
Ofte stilte spørsmål
Hva er den tekniske forskjellen på REST og SOAP?
SOAP er en protokoll som sender tunge XML-meldinger etter en streng kontrakt, ofte over flere transportmåter. REST er en enklere stil som bruker nettets egne verb over HTTP og som regel JSON, som er et lettere format. SOAP er mer formell og regeltung, REST er mer nedstrippet og raskere å komme i gang med.
Hvorfor bygges nye API-er i REST og ikke i SOAP?
REST er billigere å bygge, lettere å forstå og passer bedre for nett og mobil. Verktøyene og utviklerne finnes. SOAP krever mer struktur og tyngre verktøy, noe som sjelden lønner seg for nye tjenester. Derfor er REST standardvalget i dag, mens SOAP nesten bare dukker opp i systemer som allerede finnes.
Må vi bytte ut SOAP-integrasjonene våre?
Sjelden. En fungerende SOAP-integrasjon mot et ERP-system eller en myndighet er ofte stabil og dyr å røre. Det vanlige er å la den være og i stedet kapsle den inn bak et moderne grensesnitt slik at nye deler slipper å snakke SOAP direkte. Bytt bare hvis det gamle virkelig står i veien.
Hva betyr det å kapsle inn SOAP bak en adapter?
En adapter er et lite mellomlag som snakker SOAP med det gamle systemet på den ene siden og REST med de nye tjenestene deres på den andre. Den oversetter mellom de to verdenene. Utviklerne deres kan jobbe mot et rent, moderne grensesnitt, mens kompleksiteten i SOAP gjemmes bort på ett sted.
Er SOAP mindre sikker enn REST?
Nei, i noen henseender snarere tvert imot. SOAP har modne, innebygde standarder for sikkerhet og pålitelighet som ble utviklet nettopp for behovene til store virksomheter og offentlig sektor. REST baserer seg på nettets egen sikkerhet. Forskjellen handler mer om alder, tyngde og verktøy enn om at det ene skulle være usikkert.