SOAP - What's the point?

Question

I mean, really, what is the point of SOAP?

Web services have been around for a while, and for a while it seemed that the terms 'SOAP' and 'Web service' were largely interchangeable. However SOAP always seemed unwieldy and massively overcomplicated to me.

Then REST came along, and suddenly web services made sense.

As Joel Spolsky says, give a programmer a REST URL, and they can start playing with the service right away, figuring it out.

SOAP is obfuscated behind WSDLs and massively verbose XML, and despite being web based, you can't do anything as simple as access a SOAP service with a web browser.

So the essence of my question is:

• Are there any good reasons to ever choose SOAP over REST?
• Are you working with SOAP now? Would it be better if the interface was REST?
• Am I wrong?

Abbieabbot

Answer 1

Well it appears now that the WSI agree that SOAP no longer has a point as they have announced they will cease to exist as an independent entity.

Interesting article about the announcement and some commentary here: http://blogs.computerworlduk.com/simon-says/2010/11/the-end-of-the-road-for-web-services/index.htm

Edited to be completely accurate in response to John Saunders.

Abbieabbot

-1: @Dan: SOAP and the WS-* specifications are W3C, not WS-I (w3.org/TR/soap) – Frisse

@John, would it be correct to say that the WS-* specifications driven by OASIS/WSI then ratified (or refined) by the W3C? If that's the case, unless another group takes the initiative, isn't new development for these standards effectively finished? – Cheerful

@Jeff: WS-I is just an interoperability group. I don't believe they had anything to do with the standard. The standards have always been owned by w3c. – Frisse

you've totally misread this. WS-I, the interoperability group, are being folded into OASIS, the standardization group. If anything, this says that the interoperability problem has become sufficiently mainstream, that it no longer needs a separate organization. – Frisse

Answer 2

As Joel Spolsky says, give a programmer a REST URL, and they can start playing with the service right away, figuring it out.

Whereas if the service had a well specified, machine readable contract, then the programmer wouldn't have to waste any time figuring it out.

(not that WSDL/SOAP is necessarily an example of good implementation of a well specified contract, but that was the point of WSDL)

Originally, SOAP was a simple protocol which allowed you to add a header to a message, and had a standardized mapping of object instances to XML structures. Putting the handling metadata in the message simplified the client code, and meant you could very simply persist and queue messages.

I never needed the header processing details when I built SOAP services back in 2001. This was pre-WSDL, and it was then normal to use GET for getting information and queries (no different to most applications which claim to be REST; REST has more in terms of using hyperlinks for service discovery) and POST with a SOAP payload to perform actions. Those actions which created resources would return the URL of the created resource to the client, and the client could then GET the resource. I think it's the fact that WSDL made it easy to think only in terms of RPC rather than actions which create resources which made SOAP lose the plot.

Nichrome

Answer 3

The topic is well-discussed in Why is soap considered to be thick.

Ungual

Yep, I said my piece in that thread. Check there for my comments. – Humanoid

Answer 4

The way I see it, SOAP might be more "flexible", but as a result it's just way too complicated (you mentioned the WSDL, which is always a stumbling block to me personally).

I get REST. It's simple. The only downside I might see is that you are limiting yourself to those 4 basic actions against a single resource, which might not exactly fit the way you view your data.

Basie

Answer 5

While doing some research to understand some of the answers here (especially John Saunders') I found this post http://harmful.cat-v.org/software/xml/soap/simple SOAP is more insane than I thought...

Abbieabbot

Can you paraphrase the contents of what you linked here, in case the link vanishes? If it does, your post will make absolutely no sense. – Eleanoreleanora

@tim - updated the answer with a new link to the same content that works – Abbieabbot

the link no longer works. So perhaps paraphrasing would have been useful ;-) – Ironlike

Answer 6

The point of WSDL was auto-discovery. The idea was that you wouldn't have to write client code, it would be auto-generated.

BTW. next step beyond WSDL are Semantic Web Services.

Jeep

If it did, you wouldn't ask this question ;-) – Jeep

Answer 7

If you don't need the features of the WS-* series of protocols; if you don't need self-describing services; if your service cannot be completely described as resources, as defined by the HTTP protocol; if you don't like having to author XML for every interaction with the service, and parse it afterwards; then you need SOAP.

Otherwise, sure, use REST.

---

There's been some question about the value of a self-describing service. My imagination fails me when it comes to imagining how anyone could fail to understand this. That's on me. Still, I have to think that anyone who has ever used a service much more complicated than "Hello, world" would know why it is valuable to have someone else write the code that accepts parameters, creates the XML to send to the service, sends it, receives the response, then turns that back into objects.

Now, I suppose this might not be necessary when using a RESTful service; at least not with a RESTful service that does not process complex objects. Even with a relatively simple service like http://www.earthtools.org/webservices.htm (which I've used as an example of calling a RESTful service), one benefits from understanding the structure of the returned data. Even the above service provides an XML Schema - it unfortunately doesn't describe the entire response. Given that schema one still has to manually process the XML, or else use a tool to produce serializable classes from the schema.

All of this happens for you when the service is described in a WSDL, and you use a tool like "Add Service Reference" in Visual Studio, or the svcutil.exe program, or I-forget-what-the-command-is-in-Eclipse.

If you want examples, start with the EarthTools services, and go on to any other services with more complicated messaging.

BTW, another thing that requires self-description is description of the messaging patterns and protocols supported by the service. Perhaps that's not required when the only choices are HTTP verbs over HTTP or HTTPS. Life gets more complicated if you're using WS-Security and friends.

Frisse

When do you need a self-describing service? What can't be completely be described by HTTP. I don't want to be argumentative, but some concrete examples would really help my understanding. – Abbieabbot

HTTP doesn't describe anything. It doesn't describe the structure of the messages, what operations are available, etc. It does nothing to help create client programs to call the service. – Frisse

Yeah, those aren't really examples. A REST service can have API documentation, that describes how it works. Every SOAP service I've used has also needed API documentation. So what does SOAP actually buy you in practice? Please demonstrate with an example if possible. – Abbieabbot

What people fail to recognize is that a well designed REST service has a very well defined set of contracts. They are called Media Types. iana.org/assignments/media-types Combined with the Http protocol you have a very well defined service. – Manifold

If a "REST" service delivers application/xml or application/json and expects a client to have prior knowledge of the format then they are missing the point. Yes, I know you can show me a 1001 examples where this is the case. Sigh. – Manifold

@Darrel: A SOAP service, using a WSDL, can give the client the knowledge of the format. And of the security requirements, and of the possible faults that can be returned, etc. It's not lightweight, but it wasn't meant to be lightweight. If you need light, stick with REST. – Frisse

@JonSaunders Maybe it can at compile time using client side proxy code generation. I would be very interested to hear about people using it at runtime to do discovery of formats. – Manifold

@Darrel: Runtime is compile time these days. Look up "CodeDom" on MSDN. Also, tools like SSIS and Windows Workflow Foundation configure their ability to talk to a web service by reading the WSDL. This is not new, and not rocket science. – Frisse

Answer 8

I find that SOAP fits in most appropriately when there is a high probability that a service will be consumed by corporate off the shelf (COTS) software. Because of the well specified contract employed by SOAP/WSDL most COTS packages have built in functionality for consuming such services. This can make it easy for BPM/workflow tools etc. to simply consume defined services without customization. Beyond that service use case REST tends to be my goto web service implementation for applications.

Laurinda

Answer 9

I think SOAP appeals to the Java and .net crowd who may be more familiar with the old CORBA and COM and less familiar with internet technologies.

REST also has one major drawback: there is very little guidance on how to actually implement such a system. You will find significant variations on how many of the public RESTful APIs have been designed. In fact many violate key aspects of REST (such as using GET for manipulation or POST for retrieval) and there are disagreements over fundamental usage (POST/GET vs POST/GET/PUT/DELETE).

Jimmy

I think SOAP appeals to people who have tool support. If you know you have no support, and will have to do all of the XML or JSON processing yourself, then I can see where you'd want things to be as simple as possible. But if you can have tools, then there has to be metadata to give to the tools. – Frisse

Answer 10

Am I wrong?

"You're not wrong, Walter, you're just... :)"

Are there any good reasons to ever choose SOAP over REST?

SOAP, to my understanding adheres to a contract, thus can be type checked.

Myranda

Quote is from the Big Lewbowski...fwiw. – Myranda

Answer 11

SOAP is a lightweight XML based structured protocol specification to be used in the implementation of services . It is used for exchanging structured information in a decentralized, distributed environment. SOAP uses XML technologies for exchanging of information over any transport layer protocol. It is independent of any particular programming model and other implementation specific semantics. Learn More about XML SOAP Messaging Framework

XML-based messaging framework that is 1) Extensible : Simplicity remains one of SOAP's primary design goals. SOAP defines a communication framework that allows for features such as security, routing, and reliability to be added later as layered extensions

2) Inter operable : SOAP can be used over any transport protocol such as TCP, HTTP, SMTP. SOAP provides an explicit binding today for HTTP.

3) Independent : SOAP allows for any programming model and is not tied to Remote procedure call(RPC). SOAP defines a model for processing individual, one-way messages. SOAP also allows for any number of message exchange patterns (MEPs) .Learn more about SOAP

Spunky