REST eller SOAP i jeres integrationer?
REST er den lette, HTTP- og JSON-baserede måde at bygge nye API’er på og er standard i dag. SOAP er en ældre, kontrakttung XML-protokol der lever videre i myndigheds- og enterprisesystemer. Nye integrationer laves i REST, men eksisterende SOAP-tjenester indkapsles som regel bag en moderne grænseflade i stedet for at blive bygget om.
SOAP føles for mange som et ord fra en anden tid, og på en måde er det netop det. Men prøv at koble jeres systemer sammen med en myndighed, en bank eller et etableret ERP-system, og chancen er stor for at SOAP stadig sidder der. Spørgsmålet er derfor sjældent “REST eller SOAP” på et blankt stykke papir, men hvordan det moderne skal møde det der allerede findes. Her er forskellene og en strategi der holder.
Forskellen kort fortalt
Både REST og SOAP er måder at lade systemer udveksle data på, men de kommer fra forskellige epoker og tænker forskelligt.
SOAP er en protokol. Den sender beskeder som XML efter en streng, formel kontrakt der beskriver præcis hvordan hvert kald skal se ud. Kontrakten er tung, men entydig, og SOAP har indbyggede standarder for sikkerhed og pålidelighed. Den blev bygget til en verden af store virksomhedssystemer der havde brug for formelle garantier.
REST er snarere en stil end en protokol. Den bruger nettets egne verber (hent, opret, opdater, slet) direkte over HTTP og sender som regel letvægts-JSON i stedet for tung XML. Den er skrabet, hurtig at komme i gang med og passer naturligt til web og mobil. Hvor SOAP er formel og regeltung, er REST let og pragmatisk.
Hvorfor nye API’er bygges i REST
Når nogen i dag bygger et nyt API, er svaret næsten altid REST, og grundene er praktiske snarere end ideologiske. REST er billigere at udvikle, lettere for nye udviklere at forstå og har en moden værktøjskæde hvor det meste allerede er løst. JSON er let at læse og vejer lidt over nettet, hvilket betyder noget for mobilapps.
SOAP kræver mere: tungere værktøjer, mere struktur omkring hvert kald og en formalisme der sjældent tjener sig hjem for en ny tjeneste. Så for alt der bygges fra bunden, er REST standardvalget, og SOAP er i praksis noget man møder, ikke noget man vælger.
Hvorfor SOAP-integrationerne alligevel består
Samtidig forsvinder SOAP ikke, og det er der gode grunde til. Store systemer bliver ikke udskiftet fordi teknologien bag deres grænseflader føles gammel. En SOAP-tjeneste som en myndighed, en bank eller en ERP-leverandør stiller til rådighed, er ofte stabil, velafprøvet og noget I ikke har indflydelse på. I må integrere med den som den er.
At bygge en velfungerende SOAP-integration om koster penge uden i sig selv at give ny værdi. Den gør allerede sit arbejde. Derfor lever SOAP videre, ikke som et aktivt valg, men som en realitet i systemlandskabet, især i offentlig sektor og etableret industri hvor systemers levetid måles i årtier.
Pointen er at jeres nye dele ikke behøver at arve den byrde. Udfordringen er at lade moderne og gammelt eksistere side om side uden at det gamle smitter af på alt andet.
Adapterstrategien: indkapsl det gamle
Det mønster der næsten altid er det rigtige, hedder adapter eller indkapsling. I stedet for at lade jeres nye tjenester tale SOAP direkte bygger I et lille mellemlag der laver oversættelsen ét sted.
Adapteren taler SOAP med det gamle system på den ene side og tilbyder en ren, moderne REST-grænseflade på den anden. Al kompleksiteten (den tunge XML, den formelle kontrakt, særhederne) indkapsles dér. Jeres udviklere bygger mod en moderne grænseflade og behøver aldrig at vide at der sidder en SOAP-tjeneste i bunden.
Fordelene er flere:
- Kompleksiteten samles. SOAP-særhederne findes ét sted i stedet for at være smurt ud over hver ny tjeneste.
- Det nye holdes rent. Nye apps og integrationer taler kun moderne REST.
- Fremtidssikringen bliver enklere. Bliver det gamle system udskiftet en dag, er det nok at ændre adapteren, ikke alt der ligger bag den.
Et konkret scenarie
Lad os sige at I skal bygge en ny kundeportal der skal hente data fra et ERP-system hvis eneste grænseflade er SOAP. Det ville være muligt at lade portalens kode tale SOAP direkte, men det ville sprede XML-håndteringen gennem hele appen og binde den tæt til ERP-systemets særheder.
I stedet bygger I en adapter. Den kalder ERP-systemets SOAP-tjeneste, modtager XML-svaret og oversætter det til ren JSON som portalen kan bruge. Portalen ser kun et pænt REST-API. Skulle ERP-systemet senere blive skiftet ud med et der har et moderne API, ændrer I adapteren og lader portalen være. Det gamle og det nye lever side om side uden at det ene hindrer det andet.
Vi hos Weapp bygger både nye REST-API’er og de adaptere der binder dem sammen med ældre systemer. Vil I modernisere uden at smide det ud der virker? Se vores ydelser eller kontakt os.
Ofte stillede spørgsmål
Hvad er den tekniske forskel på REST og SOAP?
SOAP er en protokol der sender tunge XML-beskeder efter en streng kontrakt, ofte over flere transportformer. REST er en enklere stil der bruger nettets egne verber over HTTP og som regel letvægts-JSON. SOAP er mere formel og regeltung, REST er mere skrabet og hurtigere at komme i gang med.
Hvorfor bygges nye API’er i REST og ikke i SOAP?
REST er billigere at bygge, lettere at forstå og passer bedre til web og mobil. Værktøjerne og udviklerne findes. SOAP kræver mere struktur og tungere værktøjer, hvilket sjældent betaler sig for nye tjenester. Derfor er REST standardvalget i dag mens man næsten kun støder på SOAP i systemer der allerede findes.
Er vi nødt til at udskifte vores SOAP-integrationer?
Sjældent. En velfungerende SOAP-integration med et ERP-system eller en myndighed er ofte stabil og dyr at røre ved. Det almindelige er at lade den være og i stedet indkapsle den bag en moderne grænseflade så nye dele slipper for at tale SOAP direkte. Skift den kun ud hvis det gamle virkelig står i vejen.
Hvad menes med at indkapsle SOAP bag en adapter?
En adapter er et lille mellemlag der taler SOAP med det gamle system på den ene side og REST med jeres nye tjenester på den anden. Det oversætter mellem de to verdener. Jeres udviklere kan arbejde mod en ren, moderne grænseflade mens kompleksiteten i SOAP er gemt væk ét sted.
Er SOAP mindre sikkert end REST?
Nej, snarere tværtimod i visse henseender. SOAP har modne, indbyggede standarder for sikkerhed og pålidelighed som blev udviklet netop til enterprise- og myndighedsbehov. REST forlader sig på nettets egen sikkerhed. Forskellen handler mere om alder, vægt og værktøjer end om at det ene skulle være usikkert.