Is SOAP obsolete?

Question

What is the current best practice for implementing Web Services? Is it still with SOAP?

Windows Communication Framework is seemingly better, but isn't it SOAP under the covers?

Answer 1

I'd say it depends on what you want :

• If you want something clearly defined (with something to describe your web service's interface), SOAP is great, with its WSDL mechanism, that describes the interface of the web service.
• If you want something a bit less "heavy", REST is quite nice

You might want to take a look at some other questions/answers about those ; for instance :

• SOAP or REST
• Performance of SOAP vs. XML-RPC or REST
• SOAP - What’s the point?
• WSDL vs REST Pros and Cons
• Why would one use REST instead of Web services?

In my opinion, REST vs SOAP depends on the situation : if you like the ability to have a self-describing web service, that exposes its API through a file whose format is well-defined, SOAP is great.

Answer 2

WCF is using SOAP at its heart - I don't see any indication that SOAP is "dead" or will be soon.

There is a trend to use REST for certain scenarios where it makes sense - but I don't think REST can totally replace SOAP. Both technologies have their pros and cons and therefore are useful for a given set of scenarios.

REST is and feels more "lightweight" - you have the standard HTTP verbs GET, PUT, POST, DELETE and those basically map to your typical CRUD operations. You can just "bang" on a URL and get back some XML. However - you don't really have a "service description", e.g. there's by default no way to describe what services are available, and what data they expect and return - at least not in a machine-readable form (sure - you can have a "doc" page which your users can read - but that's not available to tools, in order to create a client for the service).

SOAP on the other hand is more geared towards cases when you need to have total control over the message format going back and forth (since the WSDL/XSD combo gives you strict method and message signatures, a full-blown and type-safe client can be constructed from those bits of information). So SOAP is probably more geared towards communications inside and between enterprises, when type-safety and total control is a plus (and the extra steps to get there aren't considered a big handicap).

So: SOAP is here to stay.

Marc

Answer 3

It depends. I'd say that the current trend is that SOAP & XML-RPC are overly complex for many needs. The "big" man on campus for now is REST.

In a nutshell, REST exposes resources via the HTTP POST|GET|PUT|DELETE requests. These allow you to create, read, update, and delete (CRUD) respectively.

Answer 4

Also, I hope you do not want to implement a public web interface to your service in some MS technology (actually I don't know WCF, but I suppose it is not as well supported on other platforms as well defined open standards) especially with more and more clients being mobile devices.

If you want to address mobile devices as well, I think some JSON RPC or REST is the way to go, as you have to keep in mind, that those clients have very limited bandwidth, battery power, processing power and memory. From my experience, trying to poll rather large XML-documents in the background on a mobile can significantly reduce battery life, eat CPU and memory (so that foreground applications become clunky).