Everybody loves a clean JSON endpoint, but the code that keeps the lights on still speaks XML with a straight face.
If you ship software across companies or stacks, you end up speaking WS star whether you like it or not.
Put WS star in context. It was built for interoperability across vendors, not weekend hacks. When you need reliable messaging, message level security, routing, or identity claims that move end to end, the SOAP plus WSDL plus WS Security plus WS Addressing combo gives you a menu of features that plain REST does not try to cover. Think of it as a contract with knobs. The WSI Basic Profile exists so that .NET, Java, SAP, and mainframes can agree on what a conforming message looks like. That profile is boring by design, and boring is good when the CFO cares more about invoices clearing than about your HTTP purity ring. The flip side is obvious. The more specs you add, the higher the chance your partner’s stack reads a header differently or a policy assertion turns into a support ticket. WS star is not hard because XML is scary. It is hard because it gives you many ways to be right and still not match.
The quiet hero of WS star is not the spec sheet, it is the tooling. Visual Studio can Add Service Reference and emit a client that handles WS Policy, security bindings, and SOAP faults without you touching a bit. On the Java side, Eclipse and JAX WS tools generate stubs, handle document literal messages, and wire handlers for headers. SoapUI lets you poke at WSDLs, fuzz inputs, and replay sessions. These tools make contract first workable. You lock the WSDL and XSD, share them early, and let code gen do the boring mapping. Trouble starts when we wander off the well lit path. Vendor extensions creep into WSDLs. Someone flips on reliable messaging across the board. A policy says client certs and the other team expects a token. Before you know it the client proxy has thirty config knobs and every knob moves in pairs. Keep the WSDL small and literal, prefer message level security only when needed, and test with the WSI tools against real partners, not just the lab build.
So when do you choose WS star over REST with JSON. It is not a street fight. It is a fit question. For public developer facing APIs, mobile apps, feeds, and quick mashups, REST wins by default because it is easy to consume and cache, and the browser speaks it natively. For B2B contracts, purchase orders, claims, settlements, and anything that needs signed and encrypted envelopes that hop through a broker or two, WS star still pays the bills. If you need SAML tokens inside messages, if your partner requires WS Security UsernameToken or mutual certs, if your auditors ask for non repudiation, the SOAP envelope is your friend. If your only need is HTTPS with a bearer token, keep it simple with REST. Make the interface boring, keep schemas stable, version with new operations and new namespaces, and publish a contract package that includes WSDL, XSD, sample messages, policy, and a short human readme. Avoid cute. Your future self will send you cookies.
Let us get tactical. Start with document literal wrapped. Avoid rpc styles and odd encodings. Keep schemas flat and predictable. Namespaces are not decoration. Treat them as a version switch and use them when you must break shape. Prefer additive changes that old clients can ignore. Make faults first class with clear codes and human text. Map them to HTTP codes where it makes sense. Keep WS Addressing off unless you need decoupled messaging or a broker that rewrites headers. If you need reliability, try to buy it from the transport first. Queues like MSMQ, Service Bus, or JMS can do a lot before you reach for WS Reliable Messaging. For security, start with HTTPS and a simple token. Add message signing only when your path or broker requires it. Keep policy files in source control, promote them along your environments, and test them as code. And never ship a service without a SoapUI project that proves the key flows end to end.
Interoperability is a social contract as much as a tech spec. The best WSDL in the world will not save you from mismatched expectations. Put a real contact on your service page. Agree on payload examples. Decide what happens when timeouts hit or signatures fail. Swap Fiddler or tcpdump traces when something smells odd. If the other side is stuck on an old stack, meet them in the middle with the profile they can handle. Keep a minimal surface area. Push exotic requirements to fewer endpoints instead of sprinkling them everywhere. And if a partner says their tool only works with a specific binding, do not fight a holy war. Give them a binding that still matches the WSI Basic Profile, mark it as partner specific, and move on. Time to value beats style points every single time.
Pick the boring tech that lets different teams agree, and your tools will do the heavy lifting while you ship.