REST eller SOAP i era integrationer?

SOAP känns för många som ett ord från en annan tid, och på sätt och vis är det just det. Men försök koppla ihop era system med en svensk myndighet, en bank eller ett etablerat affärssystem, och chansen är stor att SOAP fortfarande sitter där. Frågan är därför sällan “REST eller SOAP” på ett rent bord, utan hur det moderna ska möta det som redan finns. Här är skillnaderna och en strategi som håller.

Skillnaden i korthet

Både REST och SOAP är sätt att låta system utbyta data, men de kommer ur olika epoker och tänker olika.

SOAP är ett protokoll. Det skickar meddelanden som XML enligt ett strikt, formellt kontrakt som beskriver exakt hur varje anrop ska se ut. Kontraktet är tungt men entydigt, och SOAP bär inbyggda standarder för säkerhet och tillförlitlighet. Det byggdes för en värld av stora företagssystem som behövde formella garantier.

REST är snarare en stil än ett protokoll. Den använder webbens egna verb – hämta, skapa, uppdatera, ta bort – direkt över HTTP, och skickar vanligtvis lättviktig JSON i stället för tung XML. Det är avskalat, snabbt att komma igång med och passar webb och mobil naturligt. Där SOAP är formellt och regeltyngt är REST lätt och pragmatiskt.

Varför nya API:er byggs i REST

När någon idag bygger ett nytt API är svaret nästan alltid REST, och skälen är praktiska snarare än ideologiska. REST är billigare att utveckla, lättare för nya utvecklare att förstå och har en mogen verktygskedja där det mesta redan är löst. JSON är lätt att läsa och väger lite över nätet, vilket spelar roll för mobilappar.

SOAP kräver mer: tyngre verktyg, mer struktur runt varje anrop och en formalism som sällan betalar tillbaka sig för en ny tjänst. Så för allt som byggs från grunden är REST förvalet, och SOAP är i praktiken något man möter – inte något man väljer.

Varför SOAP-integrationerna ändå består

Samtidigt försvinner inte SOAP, och det finns goda skäl till det. Stora system byts inte ut för att tekniken bakom deras gränssnitt känns gammal. En SOAP-tjänst som en myndighet, en bank eller en affärssystemsleverantör tillhandahåller är ofta stabil, väl beprövad och något ni inte råder över. Ni får integrera mot den som den är.

Att bygga om en fungerande SOAP-integration kostar pengar utan att ge något nytt värde i sig. Den gör redan sitt jobb. Därför lever SOAP kvar, inte som ett aktivt val utan som en realitet i systemlandskapet – särskilt i svensk offentlig sektor och etablerad industri, där livslängden på system mäts i decennier.

Poängen är att era nya delar inte behöver ärva den bördan. Utmaningen är att låta modernt och gammalt samexistera utan att det gamla smittar av sig på allt annat.

Adapterstrategin: kapsla in det gamla

Det mönster som nästan alltid är rätt heter adapter, eller inkapsling. I stället för att låta era nya tjänster prata SOAP direkt bygger ni ett litet mellanlager som gör översättningen på ett enda ställe.

Adaptern talar SOAP mot det gamla systemet på ena sidan och erbjuder ett rent, modernt REST-gränssnitt på den andra. All komplexitet – den tunga XML:en, det formella kontraktet, särdragen – kapslas in där. Era utvecklare bygger mot ett modernt gränssnitt och behöver aldrig känna till att det sitter en SOAP-tjänst i botten.

Fördelarna är flera:

• Komplexiteten samlas. SOAP-särdragen finns på ett ställe i stället för utsmetade i varje ny tjänst.
• Det nya hålls rent. Nya appar och integrationer pratar bara modernt REST.
• Framtidssäkringen blir enklare. Byts det gamla systemet ut en dag räcker det att ändra adaptern, inte allt som ligger bakom den.

Ett konkret scenario

Säg att ni ska bygga en ny kundportal som behöver hämta data ur ett affärssystem vars enda gränssnitt är SOAP. Att låta portalens kod prata SOAP rakt av vore möjligt, men det skulle sprida XML-hanteringen genom hela appen och binda den hårt till affärssystemets egenheter.

I stället bygger ni en adapter. Den anropar affärssystemets SOAP-tjänst, tar emot XML-svaret och översätter det till ren JSON som portalen kan använda. Portalen ser bara ett snyggt REST-API. Skulle affärssystemet längre fram bytas mot ett med ett modernt API, rör ni adaptern och lämnar portalen orörd. Det gamla och det nya lever sida vid sida, utan att det ena hindrar det andra.

Vi på Weapp bygger både nya REST-API:er och de adaptrar som håller ihop dem med äldre system. Vill ni modernisera utan att slänga det som fungerar? Titta på våra tjänster eller hör av dig.