SOAPless
Sign Up
Back to Blog
frontendcorsbffsoap

Browser Apps, SOAP to REST, CORS, and Why You Still Might Want a BFF

SOAPless Team4 min read

If a frontend team inherits a SOAP dependency, the first instinct is usually:

Fine. Put a REST facade in front of it and call that from the browser.

That instinct is directionally right, but it skips the part that actually hurts in production:

  • cross-origin requests
  • API key placement
  • session boundaries
  • enterprise allowlists
  • whether the API hostname itself creates friction

The problem is not just SOAP. The problem is browser delivery.

Why frontend teams want this in the first place

Frontend teams do not want to think about:

  • text/xml
  • SOAPAction
  • namespace prefixes
  • WS-Security headers
  • request envelopes that break because one integer was sent as "value"

They want:

  • JSON
  • OpenAPI
  • predictable methods
  • testable examples

That part is completely reasonable. A REST facade is often the fastest way to give them that contract.

Where browser reality shows up

Once the caller is a browser app, the integration is no longer just about message format.

The browser enforces origin rules. If your app is served from one origin and the facade is served from another, the server needs to return the right CORS headers and may need to answer a preflight request first. MDN documents this clearly: cross-origin fetch() calls are blocked unless the response explicitly allows the origin and method combination you are trying to use.

That means the browser version of the problem becomes:

  • Can the origin call the API?
  • Will an Authorization or custom header trigger preflight?
  • Are credentials sent safely?
  • Is the API key exposed in client-side code?

When a facade is enough

A hosted SOAP-to-REST layer is usually enough if:

  • the caller is server-side
  • you already have a backend or server action layer
  • your app uses a BFF pattern
  • API secrets stay on the server

In those cases, the frontend still gets JSON and stable endpoint behavior, but the security and origin concerns stay in a place that is easier to control.

When a BFF is still the correct answer

A thin BFF is still the safer default if:

  • the browser would otherwise hold a production API key
  • you need per-user authorization instead of one shared integration credential
  • customer security teams want a same-origin or first-party story
  • you need to combine multiple upstream systems into one frontend response

This is not “extra architecture for the sake of architecture.” It is the layer that keeps browser concerns separate from integration concerns.

SOAP to REST did not remove every boundary

It removed the XML pain. It did not remove browser security rules.

That distinction matters because teams often evaluate the wrong thing. They ask:

Can we turn SOAP into REST?

The better question is:

After we turn SOAP into REST, who is calling it, from where, and with what trust boundary?

A practical decision rule

Use a SOAP-to-REST facade directly when:

  • the caller is backend code
  • internal automation owns the credential
  • you mainly need easier request and response handling

Put a BFF in front when:

  • the caller is a public browser app
  • secrets would otherwise leak to the client
  • CORS and domain trust are part of the delivery problem

Why custom domains often come up next

Once browser delivery or enterprise review enters the picture, the next request is often a customer-owned domain.

That is because teams want:

  • simpler allowlists
  • a cleaner first-party hostname
  • fewer procurement questions about where production traffic goes

So if the use case is a browser-facing product, the roadmap conversation usually becomes:

  1. get out of XML
  2. make the API browser-safe
  3. make the API domain enterprise-safe

If you only solve step 1, you have still made progress. But you have not solved the full frontend delivery problem.

Back to Blog