Enterprise Integration Zone is brought to you in partnership with:

Jagadeesh is a DZone MVB and is not an employee of DZone and has posted 27 posts at DZone. You can read more from them at their website. View Full User Profile

Compare RESTful vs SOAP Web Services

03.08.2013
| 104218 views |
  • submit to reddit
There are currently two schools of thought in developing Web Services – one being the standards-based traditional approach [ SOAP ] and the other, simpler school of thought [ REST ].

This article quickly compares one with the other -

REST SOAP
Assumes a point-to-point communication model–not usable for distributed computing environment where message may go through one or more intermediaries Designed to handle distributed computing environments
Minimal tooling/middleware is necessary. Only HTTP support is required Requires significant tooling/middleware support
URL typically references the resource being accessed/deleted/updated The content of the message typically decides the operation e.g. doc-literal services
Not reliable – HTTP DELETE can return OK status even if a resource is not deleted Reliable
Formal description standards not in widespread use. WSDL 1.2, WADL are candidates. Well defined mechanism for describing the interface e.g. WSDL+XSD, WS-Policy
Better suited for point-to-point or where the intermediary does not play a significant role Well suited for intermediated services
No constraints on the payload Payload must comply with the SOAP schema
Only the most well established standards apply e.g. HTTP, SSL. No established standards for other aspects.  DELETE and PUT methods often disabled by firewalls, leads to security complexity. A large number of supporting standards for security, reliability, transactions.
Built-in error handling (faults) No error handling
Tied to the HTTP transport model Both SMTP and HTTP are valid application layer protocols used as Transport for SOAP
Less verbose More verbose
Published at DZone with permission of Jagadeesh Motamarri, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Comments

Greg Brown replied on Fri, 2013/03/08 - 10:13am

There are a lot of inaccuracies here, but the most significant one is reliability. Using your example, SOAP is no more reliable than REST. I could very easily write a SOAP method that is supposed to delete some resource and returns true even if the resource is not actually deleted. This is an issue of developer error, not protocol reliability.


Aaron Anderson replied on Fri, 2013/03/08 - 6:56pm in response to: Greg Brown

Premise: a service running on a Java appserver is behind a web server.


Consider these scenarios: 

1) Web Service

Delete request comes into a SOAP Web Service which processes it and returns in the SOAP envelope a body for sucess or a fault for an error. However, the web server malfunctions and a HTTP 500 error code is returned. Because no SOAP Fault is observed by the client the error may be attributed to a transport problem as opposed to a service problem.

 

2) REST Service

Delete request comes into a REST Service which processes it and returns a 200 OK. However, the web server malfunctions and a HTTP 500 error code is returned. Based on the error code and/or response code it is difficult to determine if the error is due to a transport problem or a service problem.

Bakary Djiba replied on Fri, 2013/03/08 - 7:03pm

Thank you for this comparison.

I am agree with Greg about reliability. Because if you refer only to the HTTP's status with REST, you will have mistake. 

First the "OK" message (HTTP 200 status code) is returned when the http request is well received by your server and "processed". You have to manage the deletion process and return a custom result which can give you the state of your operation into the HTTP response object.

M Leslie replied on Sat, 2013/03/09 - 2:30pm

Couldnt agree more with Greg. Lot of this boils down to how the developers understand the concepts and implement it. I recently worked on a project where they had used Jersey to create REST services. No HTTP error codes were used. Any errors were returned using strings which meant that you had to parse the results to find out if the service call was successful rather than just looking at the headers. 

Abdullah Alshammari replied on Sun, 2013/03/10 - 7:12pm

Agree with the article content in general but I don't know why you mentioned J2EE in the title, it does not make sense to use J2EE in the title while the article talking about web services in general, Thanks.

Jagadeesh Motamarri replied on Sun, 2013/03/10 - 10:05pm in response to: Abdullah Alshammari

I agree! I actually run a blog focusing Java and J2EE content and prefixed the title with J2EE although this is a general web services topic. I am renaming the title as per your suggestion. Thank You!  

Bob Miner replied on Wed, 2013/03/13 - 8:37am

The author clearly doesn't understand REST web services.  A REST web service can and should use HTTP Status Codes to indicate success or failure.  There are many REST web services that do this correctly, including this one from my company, Autodesk - https://bim360.autodesk.com/api/doc/index.shtml .

The critical issues with SOAP vs. REST are performance, scalability and adding new APIs.  Once you've pulled down a SOAP WSDL file and generated proxies to call it and built your client with those definitions, it's a pain in the butt when that SOAP WSDL changes.  REST is entirely different, enabling REST service providers to add new APIs and new versions of APIs easily without disrupting clients that are using the existing ones.

On performance and scalability, read Google's advice for Android developers where they strongly recommend using REST instead of SOAP as REST uses much less bandwidth and is much faster.  New server frameworks like node.js and single page web applications always use REST.

If you need something special that REST doesn't provide - some protocol other than HTTP/S, some customized encryption - and the WSDL file is stable and you don't care about bandwidth usage, perhaps SOAP is fine for that.  But the default for modern web apps is REST.

Emeka Kanu replied on Wed, 2013/03/13 - 8:05am

The very first comparison is your table does not make sense. How can you say SOAP is designed to handle distributed computing but REST is not. By what measure do you attribute that, when presumably the search engines people use clearly make use of RESTful architecture and are shown to be not only distributable but scalable?

Robert Morschel replied on Wed, 2013/03/13 - 8:33am

There are a couple of items on this list that are just not correct:

- REST does not assume point to point

- REST is not tied to HTTP

Robert

SOA REST


Claudio Lyra replied on Thu, 2013/03/14 - 9:19pm in response to: Bob Miner

Hello Bob, 

Thanks for your good comments. Can you please provide a link to the Google advise on bandwidth and performance?

In my view, REST is definitely simpler but this simplicity can be deceptive. 

I would appreciate your opinion on the comments that follow. Do they make sense to you? Do you think these are relevant issues?

Take, for example, the use of http status codes, referred by you. It is not unusual that intermediary servers or software layers (one mistake of the author is to associate REST to point-to-point!) generate status codes that replace the code that was originally raised by the service endpoint, changing completely its logical meaning.

Or the reliance on (or the necessity of making use of) http headers to convey service related information, like content-type and location. In particular with the former, custom (business specific, non-standard) values often are simply rejected by intermediary nodes (or development frameworks).

One possible solution for these issues is to introduce custom header elements exclusively dedicated to business logic - leaving the http headers to take care of what they were originally created for, which is to convey transport information. 

But then, as with the custom header parameters proposed above, also with the definition of the message payload: although changes in wsdl and schemas in general do force (significant?) code changes and ingenious version control mechanisms (in order to cope with backward compatibility of existing clients, for example) at least the contract (payload included) is explicitly and completely defined in a single and well documented source. On the other hand, in REST, endpoint information and data type definitions are dissociated - custom header parameters and payload format must be negotiated offline - being a non trivial task to maintain a large customer base in pace with the newest versions of code.

This is not an exhaustive critique of REST (haven't talked, for ex., about POST, PUT and CRUD issues or the semantic meaning of object model oriented REST interfaces versus service or function oriented WSDL interfaces). Nothing against it, on the contrary. I am just trying to think in terms of pros and cons.

As a final note, both approaches are not designed to handle modern concerns such as security or binary (multi-part) content, for example. So no matter what is your project choice you probably will end up stuck with uncanny solutions that will cause many headaches.

Best regards,

Cláudio

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.