SOAP x RESTful WebServices

[Eduardo Bueno]

What are the benefits in using SOAP instead of RESTful WebServices?
Is SOAP mostly implemented using HTTP protocol?
Is it really more difficult than REST?
Which one is more secure or requires more security (like firewall, etc.)?
Which one Google uses?

Sorry for the spitting questions, I'm still a little confused about those. The only reference I found was Wikipedia, which didn't help much.

Thanks.

[Anselm Paulinus]

I am rather interested in knowing the advantage of REST over SOAP; the buzz world now seems to be on RESTFUL webservice and I do not think that there are a lot of people out there that have their hands dirty with the technology yet.

[Jeff. Davis]

That's a great question! Exposing your services through REST or SOAP are both excellent options. I have a slight bias towards SOAP insofar as its use of a WSDL, which really does a nice job at defining the semantics of your web service. Because of this, tooling through both .NET and Java can consume a WSDL and code-generate the binding classes needed to work with the service fairly easily. Work is being done on the REST side to provide analogous functionality to WSDL, such as the Web Application Description Language.

Another important consideration is security. The WS-Security related SOAP provides several different standards or profiles that can be used. While like many of the WS-* standards, it was fairly slow to take-hold, but now is becoming more and more adopted, such as Amazon's usage in their AWS services. REST services do have some advantage in simplicity, to be sure, but as the tooling around SOAP improves, that advantage may become less-and-less.

jeff

[Eduardo Bueno]

Thanks, I appreciate the answers.

Does anyone know about Google?

[Hussein Baghdadi]

Eduardo Bueno wrote:Thanks, I appreciate the answers.

Does anyone know about Google?

What about them?

[Ivan Krizsan]

Hi!
As far as I have understood, there is a difference in the situations in which REST respective SOAP web services are more suitable:
REST
As the name implies (Representational State Transfer), REST web services are more suitable when you have some resources that you want to apply a limited set of verbs to (commonly PUT, GET, DELETE, POST, which maps to CRUD).
Resources are uniquely identified by (commonly) an URL, for instance: http://myserver.com/library/books/12345
The URL identifies the book with id number 12345 in the library on myserver. Performing a GET to this URL would typically retrieve the representation of the book in question. A resource representation is commonly in XML or JSON.

SOAP
SOAP has commonly been used with web services that performs some kind of function, for instance addition in a calculator web service.
There are also document based SOAP web services, which, to me, seems to be closer to REST web services. A document based web service receives, for instance, an order and checks if the items in the order is available in stock or not. Note that the "verbs" are not limited, as with RESTful web services.

There is much more on this subject and there are additional considerations, as mentioned by other posters, about, for instance, web service security, tooling etc.
Then there also is RESTlike web services, which, at a glance may seem like RESTful web services but often are RPC web services implemented in a fashion that resembles RESTful web services.
Please correct me if there is anything I have misunderstood!
Best wishes!

[Anil Vupputuri]

Here are the characteristics of REST:
• Client-Server: a pull-based interaction style: consuming components pull representations.
• Stateless: each request from client to server must contain all the information necessary to understand the request, and cannot take advantage of any stored context on the server.
• Cache: to improve network efficiency responses must be capable of being labeled as cacheable or non-cacheable.
• Uniform interface: all resources are accessed with a generic interface (e.g., HTTP GET, POST, PUT, DELETE).
• Named resources - the system is comprised of resources which are named using a URL.
• Interconnected resource representations - the representations of the resources are interconnected using URLs, thereby enabling a client to progress from one state to another.
• Layered components - intermediaries, such as proxy servers, cache servers, gateways, etc, can be inserted between clients and resources to support performance, security, etc.