views:

273

answers:

4

Following "A well earned retirement for the SOAP Search API" from Google announcing they have recently removed their SOAP APIs, I'm curious what the community thinks of SOAP in 2009. I can see its use for remoting and more verbose client-server stateless communication, but for more generalised [Ajax] web usage is it now redundent?

Have REST URLs removed the need for SOAP and that kind of web service once and for all?*

*I hope so.

+2  A: 

Oh if only SOAP were dead. I can assure you that some companies are still pursuing SOAP-based, RPC strategies as fast as they can.

Hank Gay
+3  A: 

As you already said -- REST can't deal with the verbose cases.

If you can tell me how I can take an arbitrary number of complex arguments through a RESTful web service, without hitting URL length restrictions, I'd love to hear it.

But for complex queries of scientific data, we need something more than positional parameters or key/value pairs.

My prediction is that SOAP won't die until sometime after COBOL and Fortran.

Joe
If you have any distributed service endpoint where there are more parameters than fit on an URL, I would suggest there may be a better design solution.
Darrel Miller
Google Maps and Bing Maps both have problems with long routes on the URL so they haven't magically worked around this problem either.
Jared Updike
+7  A: 

SOAP is here to stay - and rightfully so.

In an enterprise environment, things like self-describing services (with the help of WSDL), ability to use transactions and reliable messaging are paramount. They're much more important than the running after the "rave of the day".

REST has its good uses - but it cannot ever replace SOAP totally, nor should it. REST is great for lightweight communcation - twittering and the like. But there's also good reason to have and know about SOAP.

SOAP currently has the much better tooling support in most environments - it'll be some time before REST has something comparable.

SOAP allows for machine-readable service description and service discovery - REST has nothing like that, your REST service might - or might not - be documented, and the quality of the English prose documenting your REST services varies wildly.

Yes, REST is all the rage right now - and it does make a lot of fun scenarios a lot easier to handle. But I don't think it's ready for "prime-time, enterprise-level" use, really. Maybe some day - but not today.

Anyone interested might also want to see the Stack Overflow question "Is SOAP obsolete?".

marc_s
It seems like SOAP was invented when XML became defacto and now people have realised the majority of the situations don't need it. You can simply post your ID or a few arguments in your REST url. And REST is basically what HTTP is about, posting a verb and some arguments to a server instead of huge chunks of dirty XML.
Chris S
@ChrisS: I think both have their place - I think the news of SOAP's death have been greatly exaggerated. Yes, of course - in many cases, REST will do just fine. But in other cases, I would pick SOAP over REST any day now. Example: how do you do secure (encrypted) message transfer in REST?? Not just connecting using SSL - actual **message encryption**. Pretty tricky.....
marc_s
And what exactly is the point of encrypting the message as opposed to using HTTPS?
André Paramés
+3  A: 

There is nothing in REST that says you can't use form POST fields to PUT data for when you need to send complex requests over. You can even post big blocks of bulky XML if you want to try and make it as SOAPy as possible.

IMHO SOAP gives you nothing but a wrapper that you never needed to begin with. The thing that killed it for me was the way Axis and other engines compile stubs of your WSDL into their code and then every time you add something to the WSDL it breaks the consumers, even if everything was designed to be backward compatible. REST forever.

ryber
SOAP isn't just a wrapper!! That misses the whole point! SOAP is a transport agnostic container of data. It's inherent strength comes from it extensibility i.e. all the other WS-* standards that can attach meta data to the data request, WS-Security for example! Rest has no concept of extension, no concept of metadata. Rest is light wieght SOAP and it traits are needed in a complex business enviroment.
Jon
You make it sound so "enterprisey". Look I write "enterprise" apps, And you dont need any of that crap. Why do you need "WS-Security"? Whats wrong with Simple HTTP authentication, or certificate based auth? Why does everything have to answer every possible problem? SOAP is nothing more than a bunch of unnecessary bloat. REST can do anything you need it to without being eternally bound into a modern day CORBA. Ill give you this, SOAP can be used over SMTP. If thats not a sign it's over engineered I don't know what is
ryber
I think you've anwsered your own question, "Why do you need WS-Security" !!!! Why do we need security at all, heh??
Jon
@Jon Just out of curiosity, when you do online banking, what security mechanism does your bank use? And when you buy stuff online with your credit card, how is that information secured?
Darrel Miller
@Jon REST has no concept of metadata because it is an architectural style and not an architecture itself. When using HTTP to do REST you use HTTP headers to store metadata. There is nothing really wrong with SOAP itself. My problem is with the vendor toolkits that push you into doing RPC style remote interfaces, where you pass serialized objects across the wire and have to deal with fragile proxy objects on the client. SOAP and the WS-* family solve some real enterprise problems where REST does not fit well. Where the HTTP protocol is good enough, REST is probably the better choice.
Darrel Miller