SOAP or REST for Web Services? [closed]

Question

Is REST a better approach to doing Web Services or is SOAP? Or are they different tools for different problems? Or is it a nuanced issue - that is, is one slightly better in certain arenas than another, etc?

Bounty-Edit:

Now, almost three years later I would like to ask this question again - offering a bounty to encourage an indepth answer. I would especially appreciate information about those concepts and their relation to the PHP-universe and also modern high-end web-applications.

Answer 1

Listen to this podcast to find out. If you want to know the answer without listening, then OK, its REST. But I really do recommend listening.

Answer 2

If you are looking for interoperability between different systems and languages, I would definately go for REST. I've had a lot of problems trying to get SOAP working between .NET and Java, for example.

Answer 3

In sense with "PHP-universe" PHP support for any advanced SOAP sucks big time. You will end up using something like http://wso2.com/products/web-services-framework/php/ as soon as you cross the basic needs, even to enable WS-Security or WS-RM no inbuilt support.

SOAP envelope creation I feel is lot messy in PHP, the way it creates namespaces, xsd:nil, xsd:anytype and old styled soap Services which use SOAP Encoding (God knows how's that different) with in SOAP messages.

Avoid all this mess by sticking to REST, REST is nothing really big we have been using it since the start of WWW. We realized only when this http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm paper came out it shows how can we use HTTP capabilities to implement RESTFul Services. HTTP is inherently REST, that doesn't mean just using HTTP makes your services RESTFul.

SOAP neglects the core capabilities of HTTP and considers HTTP just as an transport protocol, hence it is transport protocol independent in theory (in practical it's not the case have you heard of SOAP Action header? if not google it now!).

With JSON adaption increasing and HTML5 with javascript maturing REST with JSON has become the most common way of dealing with services. JSON Schema has also been defined can be used for enterprise level solutions (still in early stages) along with WADL if needed.

PHP support for REST and JSON is definitely better than existing inbuilt SOAP support it has.

Adding few more BUZZ words here SOA, WOA, ROA

http://blog.dhananjaynene.com/2009/06/rest-soa-woa-or-roa/

http://www.scribd.com/doc/15657444/REST-White-Paper

by the way I do love SOAP especially for the WS-Security spec, this is one good spec and if someone thinking in Enterprise JSON adaption definetly need to come with some thing similar for JSON, like field level encryption etc.

Answer 4

SOAP currently has the advantage of better tools where they will generate a lot of the boilerplate code for both the service layer as well as generating clients from any given WSDL.

REST is simpler, can be easier to maintain as a result, lies at the heart of Web architecture, allows for better protocol visibility, and has been proven to scale at the size of the WWW itself. Some frameworks out there help you build REST services, like Ruby on Rails, and some even help you with writing clients, like ADO.NET Data Services. But for the most part, tool support is lacking.

Answer 5

I am looking at the same, and i think, they are different tools for different problems.

Simple Object Access Protocol (SOAP) standard an XML language defining a message architecture and message formats, is used by Web services it contain a description of the operations. WSDL is an XML-based language for describing Web services and how to access them. will run on SMTP,HTTP,FTP etc. Requires middleware support, well defined mechanisam to define services like WSDL+XSD, WS-Policy SOAP will return XML based data SOAP provide standards for security and reliability

Representational State Transfer (RESTful) web services. they are second generation Web Services. RESTful web services, communicate via HTTP than SOAP-based services and do not require XML messages or WSDL service-API definitions. for REST no middleware is required only HTTP support is needed.WADL Standard, REST can return XML, plain text, JSON, HTML etc

It is easier for many types of clients to consume RESTful web services while enabling the server side to evolve and scale. Clients can choose to consume some or all aspects of the service and mash it up with other web-based services.

1. REST uses standard HTTP so it is simplerto creating clients, developing APIs
2. REST permits many different data formats like XML, plain text, JSON, HTML where as SOAP only permits XML.
3. REST has better performance and scalability.
4. Rest and can be cached and SOAP can't
5. Built-in error handling where SOAP has No error handling
6. REST is particularly useful PDA and other mobile devices.

REST is services are easy to integrate with existing websites.

SOAP has set of protocols, which provide standards for security and reliability, among other things, and interoperate with other WS conforming clients and servers. SOAP Web services (such as JAX-WS) are useful in handling asynchronous processing and invocation.

For Complex API's SOAP will be more usefull.

Answer 6

I am looking at the same issue. Seems to me that actually REST is quick and easy and good for lightweight calls and responses and great for debugging (what could be better than pumping a URL into a browser and seeing the response).

However where REST seems to fall down is to do with the fact that its not a standard (although it is comprised of standards). Most programming libraries have a way of inspecting a WSDL to automatically generate the client code needed to consume a SOAP based services. Thus far consuming REST based web services seems a more adhoc approach of writing an interface to match the calls that are possible. Making a manual http request then parsing the response. This in itself can be dangerous.

The beauty of SOAP is that once a WSDL is issued then business' can structure their logic aorund that set contract any change to the interface will change the wsdl. There isnt any room for manouvre. You can validate all requests against that WSDL. However because a WSDL doesnt properly describe a REST service then you have no defined way of agreeing on the interface for communication.

From a business perspective this does seem to leave the communication open to interpretation and change which seems like a bad idea.

The top 'Answer' in this thread seems to say that SOAP stands for Simple Object-oriented Access Protocol, however looking at wiki the O means Object not Object-oriented. They are different things.

I know this post is very old but thought I should respond with my own findings.