REST and SOAP: When Should I Use Each (or Both)?
- Share
-
- |
Read later
My Reading List
Web developers today have a myriad of technologies they can choose from; everything from simplified database access, to easy wrapping of existing middleware services, to a plethora of interesting client side software. All of these products and tools are there to give web developers the ability to create the best web-based applications in the shortest amount of time.
However, having a massive set of possible software solutions is one challenge, picking the specific approach for specific parts of the web applications is another, and web developers today have to juggle many of these decisions with changing standards or approaches seemingly appearing daily.
Take for example, the two approaches for interfacing to the web with web services, namely SOAP (Simple Object Access Protocol) and REST (Representational State Transfer). Both approaches work, both have advantages and disadvantages to interfacing to web services, but it is up to the web developer to make the decision of which approach may be best for each particular case.
By now, most developers have at least, from a periphery, been exposed to the REST approach, which uses a standard URI (Uniform Resource Identifier) that makes a call to a web service like http/https://www.mycompany.com/program/method?Parameters=xx. The approach is very simple to understand and can be executed on really any client or server that has HTTP/HTTPS support. The command can execute using the HTTP Get method. So developers that use this approach, cite the ease of development, use of the existing web infrastructure, and little learning overhead as key advantages to the style.
However SOAP, the granddaddy of all web services interfaces, is not going away anytime soon, and in fact with the introduction of SOAP 1.2 has fixed many of the perceived short-comings of the technology and pushing it to new levels of both adoption and ease-of-use. It should also be noted that the acronym SOAP no longer stands for Simple Object Access Protocol as of the 1.2 specification from the W3C organization; it is now just the name of the specification.
Now keep in mind that using SOAP 1.2 has some additional overhead that is not found in the REST approach, but that overhead also has advantages. First, SOAP relies on XML (Extensible Markup Language) in three ways; the Envelope – that defines what is in the message and how to process it, a set of encoding rules for datatypes, and finally the layout of the procedure calls and responses gathered. This envelope is sent via a transport (HTTP/HTTPS), and an RPC (Remote Procedure Call) is executed and the envelope is returned with information in a XML formatted document.
It is important to note that one of the advantages of SOAP is the use of the “generic” transport. While REST today uses HTTP/HTTPS, SOAP can use almost any transport to send the request, using everything from the afore mentioned to SMTP (Simple Mail Transfer Protocol) and even JMS (Java Messaging Service). However, one perceived disadvantage is the use of XML because of the verboseness of it and the time it takes to parse.
However, the good news for web developers is that both technologies are very viable in today’s market. Both REST and SOAP can solve a huge number of web problems and challenges, and in many cases each can be made to do the developers bidding, which means they can work across the domain.
But the untold story is that both technologies can be mixed and matched. REST is very easy to understand and is extremely approachable, but does lack standards and is considered an architectural approach. In comparison, SOAP is an industry standard with a well-defined protocol and a set of well-established rules to be implemented, and it has been used in systems both big and small.
So this means areas that REST works really well for are:
- Limited bandwidth and resources; remember the return structure is really in any format (developer defined). Plus, any browser can be used because the REST approach uses the standard GET, PUT, POST, and DELETE verbs. Again, remember that REST can also use the XMLHttpRequest object that most modern browsers support today, which adds an extra bonus of AJAX.
- Totally stateless operations; if an operation needs to be continued, then REST is not the best approach and SOAP may fit it better. However, if you need stateless CRUD (Create, Read, Update, and Delete) operations, then REST is it.
- Caching situations; if the information can be cached because of the totally stateless operation of the REST approach, this is perfect.
That covers a lot of solutions in the above three. So why would I even consider SOAP? Again, SOAP is fairly mature and well-defined and does come with a complete specification. The REST approach is just that, an approach and is wide open for development, so if you have the following then SOAP is a great solution:
- Asynchronous processing and invocation; if your application needs a guaranteed level of reliability and security then SOAP 1.2 offers additional standards to ensure this type of operation. Things like WSRM – WS-Reliable Messaging.
- Formal contracts; if both sides (provider and consumer) have to agree on the exchange format then SOAP 1.2 gives the rigid specifications for this type of interaction.
- Stateful operations; if the application needs contextual information and conversational state management then SOAP 1.2 has the additional specification in the WS* structure to support those things (Security, Transactions, Coordination, etc). Comparatively, the REST approach would make the developers build this custom plumbing.
As shown above, each technology approach has their uses. They both have underlying issues around security, transport layers, and the like, but they both can get the job done and in many cases, they each bring something to the web. So for this argument, the best rule, is the rule of flexibility, because no matter what the problem at least in today’s web development world, web developers have great solutions using either of these protocols.
About the Author
Mike Rozlog is the senior director of products for Embarcadero Technologies. In this role, he is focused on ensuring the developer focused products being created by Embarcadero meet the expectations of developers around the world. Much of his time is dedicated to discussing and explaining the technical and business aspects of Embarcadero’s products and services to analysts and other audiences worldwide. Mike was formerly with CodeGear, a developer tools group that was acquired by Embarcadero in 2008. Previously, he spent more than eight years working for Borland in a number of positions, including a primary role as Chief Technical Architect. A reputed author, Mike has been published numerous times. His latest collaboration is Mastering JBuilder from John Wiley & Sons, Inc.
Seamlessness of the Web Services approach
by
alan wilensky
To see what I mean, see ECGridOS,com and ECGridOS.net we welcome all developers no matter what your religion or what language you speak.
Not a REST vs SOAP comparision...
by
Jan Algermissen
you are not comparing REST and SOAP here, but RPC over HTTP and SOAP. Naturally, you do not see a big difference between the two :-)
When you say:
[...] the REST approach, which uses a standard URI (Uniform Resource Identifier) that makes a call to a web service like http/www.mycompany.com/program/method?Parameters=xx. The approach is very simple to understand and can be executed on really any client or server that has HTTP/HTTPS support. The command can execute using the HTTP Get method[...]
You are missing every point there is to miss about REST (sorry). What you describe is tunneling of RPC through HTTP and even with the danger of performing an unsafe operation over HTTP's safe GET method.
See nordsc.com/ext/classification_of_http_based_api... for further explanation.
Jan
Re: Not a REST vs SOAP comparision...
by
Michael Rozlog
This was not the point I was trying to make. I was trying to show a standard straight-forward call with the REST approach. I made the assumption that most readers were already aware of the REST approach and was meant as a review. Looking back at the comments, I should have went deeper into the reasons why I think REST removes complexity.
mike
Re: Seamlessness of the Web Services approach
by
Michael Rozlog
I don't understand the 90 odd functions as a problem. Take a look at Amazons Simple Storage Service and compare the REST API and the SOAP API. docs.amazonwebservices.com/AmazonS3/2006-03-01/ When doing a comparison of the implementation, I personally feel that REST offers a cleaner approach with less overhead.
However, the point I was really trying to get across is that today we don't have to make a hard-line decisions that can't be crossed with regards to Web Services. As developers we can pick the best solution or approach of each situation.
Meaning I may have X number of calls that need statefull operations, and I may have Y number of calls that are stateless. With the technologies we have today with the articles context in mind, both SOAP 1.2 and the REST approach, we can decide which approach is right for each situation. This in turn, in my opinion, is going to give the best opportunity to deliver a great overall solution.
Mike
Re: Not a REST vs SOAP comparision...
by
Kim Dalsgaard
Re: Not a REST vs SOAP comparision...
by
Michael Rozlog
This will return the XML that can be acted upon.
If you also would like I could create a step-by-step rest implementation with Delphi and show you how we have done it.
Mike
Do some more reading/research
by
Bill Burke
Re: Not a REST vs SOAP comparision...
by
Luis Espinal
http/www.mycompany.com/program/method?Parameters=xx is NOT ReST - never has been - never will be!
Depends on the interpretation. The problem is that the choice of name (method) conveys the idea of RPC over HTTP GET, even if in reality it is a badly named resource.
So, let's assume we replace 'method' with 'resource' (quaint, I know). The question now is whether 'method?param=xx' is REST or whether it should be 'method/xx'.
Like the yahoo api described by Mike below. Is it not RESTful in the strictest sense of the word because HTTP parameters accompany the URI? Would it matter in general?
Though I agree with general comments, the article left me wanting for a better comparison.
Re: Not a REST vs SOAP comparision...
by
craig schneider
Re: Not a REST vs SOAP comparision...
by
Jan Algermissen
Re: Not a REST vs SOAP comparision...
by
craig schneider
Re: Not a REST vs SOAP comparision...
by
Pablo Lalloni
REST vs SOAP or assembler vs 4GL
by
Alexander Bronshtein
Re: REST vs SOAP or assembler vs 4GL
by
Kim Dalsgaard
Re: REST vs SOAP or assembler vs 4GL
by
Alexander Bronshtein
REST, in the specific conext of HTTP and path to resources, shifts from the pure architertural style towards implementation. It is also possible to state that using some standard verb languge with additional features(kind of RPC with build in rich features) for providing services over the web leans toward architectural choice. Heading od this discussion suggests a comparison of diets with apples and oranges (or their combinations) rather than differences between apples and oranges -:)
Re: Not a REST vs SOAP comparision...
by
John McGinn
REST on the other hand exposes resources via the HTTP protocol. It is protocol specific, which is both a blessing and a curse. It's a curse because you are tied to that protocol. It's a blessing because you can take advantage of everything that protocol offers. Linking, caching, proxying, etc.
If you are happy with HTTP as your protocol REST will give you the most robust and scalable solution possible.
Re: Not a REST vs SOAP comparision...
by
Pablo Lalloni
Re: Not a REST vs SOAP comparision...
by
Alexandre Saudate
Educational Content
.jpg)
Managing Build Jobs for Continuous Delivery
Martin Peston May 24, 2013
Clojure in the Field
Stuart Halloway May 23, 2013
Tuning the Size of Your Thread Pool
Kirk Pepperdine May 23, 2013
Infoq Weekly Newsletter
Subscribe to our Weekly email newsletter to follow all new content on InfoQ
Hello stranger!
You need to Register an InfoQ account or Login to post comments. But there's so much more behind being registered.Get the most out of the InfoQ experience.
Tell us what you think