REST or SOAP in Your Integrations?

SOAP feels to many like a word from another era, and in a way, it is exactly that. But try connecting your systems to a Swedish government agency, a bank, or an established ERP, and chances are SOAP is still sitting there. The question is therefore rarely “REST or SOAP” on a clean slate, but how the modern should meet what already exists. Here are the differences and a strategy that holds up.

The difference in brief

Both REST and SOAP are ways of letting systems exchange data, but they come from different eras and think differently.

SOAP is a protocol. It sends messages as XML according to a strict, formal contract that describes exactly what each call should look like. The contract is heavy but unambiguous, and SOAP carries built-in standards for security and reliability. It was built for a world of large enterprise systems that needed formal guarantees.

REST is more a style than a protocol. It uses the web’s own verbs – fetch, create, update, delete – directly over HTTP, and typically sends lightweight JSON instead of heavy XML. It’s lean, fast to get started with, and fits web and mobile naturally. Where SOAP is formal and rule-heavy, REST is light and pragmatic.

Why new APIs are built in REST

When someone builds a new API today, the answer is almost always REST, and the reasons are practical rather than ideological. REST is cheaper to develop, easier for new developers to understand, and has a mature toolchain where most things are already solved. JSON is easy to read and light over the network, which matters for mobile apps.

SOAP requires more: heavier tooling, more structure around every call, and a formalism that rarely pays for itself in a new service. So for anything built from scratch, REST is the default, and SOAP is in practice something you encounter – not something you choose.

Why the SOAP integrations still remain

At the same time, SOAP isn’t going away, and there are good reasons for that. Large systems don’t get replaced just because the technology behind their interface feels old. A SOAP service provided by a government agency, a bank, or an ERP vendor is often stable, well-proven, and something you don’t control. You have to integrate with it as it is.

Rebuilding a working SOAP integration costs money without delivering any new value in itself. It’s already doing its job. That’s why SOAP lives on, not as an active choice but as a reality in the system landscape – especially in the Swedish public sector and established industry, where system lifespans are measured in decades.

The point is that your new parts don’t have to inherit that burden. The challenge is letting modern and old coexist without the old rubbing off on everything else.

The adapter strategy: wrapping the old

The pattern that’s almost always right is called an adapter, or wrapping. Instead of letting your new services speak SOAP directly, you build a small middle layer that does the translation in one single place.

The adapter speaks SOAP to the old system on one side and offers a clean, modern REST interface on the other. All the complexity – the heavy XML, the formal contract, the quirks – is wrapped in there. Your developers build against a modern interface and never need to know there’s a SOAP service underneath.

The benefits are several:

• The complexity is contained. The SOAP quirks live in one place instead of being smeared across every new service.
• The new stays clean. New apps and integrations only speak modern REST.
• Future-proofing gets easier. If the old system is replaced one day, it’s enough to change the adapter, not everything behind it.

A concrete scenario

Say you’re building a new customer portal that needs to fetch data from an ERP whose only interface is SOAP. Letting the portal’s code speak SOAP directly would be possible, but it would spread the XML handling throughout the entire app and bind it tightly to the ERP’s quirks.

Instead, you build an adapter. It calls the ERP’s SOAP service, receives the XML response, and translates it into clean JSON the portal can use. The portal only sees a clean REST API. If the ERP is later replaced with one that has a modern API, you touch the adapter and leave the portal untouched. The old and the new live side by side, without either one holding back the other.

At Weapp we build both new REST APIs and the adapters that tie them together with older systems. Want to modernize without throwing away what works? Check out our services or get in touch.