New-age Transactional Systems - Not Your Grandpa's OLTP
John Hugg discusses high volume transaction processing applications with high and low frequency profiles, and how VoltDB can be used for that purpose.
Article
The content has been bookmarked!
There was an error bookmarking this content! Please retry.
REST and SOAP: When Should I Use Each (or Both)?
Posted by Mike Rozlog on Apr 01, 2010
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.
- This article is part of a featured topic series on SOA
- See more SOA content at: http://www.infoq.com/soa
- Other recent content items in this topic
Seamlessness of the Web Services approach
by
alan wilensky
Posted
Re: Seamlessness of the Web Services approach
by
Michael Rozlog
Posted
Not a REST vs SOAP comparision...
by
Jan Algermissen
Posted
Re: Not a REST vs SOAP comparision...
by
Michael Rozlog
Posted
Re: Not a REST vs SOAP comparision...
by
Kim Dalsgaard
Posted
Re: Not a REST vs SOAP comparision...
by
Michael Rozlog
Posted
Re: Not a REST vs SOAP comparision...
by
Luis Espinal
Posted
Re: Not a REST vs SOAP comparision...
by
craig schneider
Posted
Re: Not a REST vs SOAP comparision...
by
Jan Algermissen
Posted
Re: Not a REST vs SOAP comparision...
by
craig schneider
Posted
Re: Not a REST vs SOAP comparision...
by
Pablo Lalloni
Posted
Re: Not a REST vs SOAP comparision...
by
John McGinn
Posted
Re: Not a REST vs SOAP comparision...
by
Pablo Lalloni
Posted
Not a joke?
by
Subbu Allamaraju
Posted
Re: Not a joke?
by
Juan Ignacio Pumarino
Posted
???
by
Yuji Kiriki
Posted
Do some more reading/research
by
Bill Burke
Posted
Re: Do some more reading/research
by
David Tkaczyk
Posted
REST vs SOAP or assembler vs 4GL
by
Alexander Bronshtein
Posted
Re: REST vs SOAP or assembler vs 4GL
by
Kim Dalsgaard
Posted
Re: REST vs SOAP or assembler vs 4GL
by
Alexander Bronshtein
Posted
-
We have a 90 odd function API that is presented as SOAP functions and a single URI pointing to a WSDL. Developers that use IDe's that "know" WSDL see our code (and EDI transit routing system) as local functions. I don't think a 90 odd verb REST service would be organized or clear enough. However, we do think that we will publish a reduced set of functions for the post get club.
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. -
Mike,
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 -
Not an April 1st joke?
-
It better be.
-
April's fool, actually...
-
Jan,
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 -
Alan,
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 -
http/www.mycompany.com/program/method?Parameters=xx is NOT ReST - never has been - never will be!
-
The layout of the call is correct, here is an example of a rest call that you can do using Yahoo: search.yahooapis.com/WebSearchService/V1/webSea...
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 -
It seems you did very little research before writing this article as a number of your assumptions and statements are incorrect. Given the quality of content that is usually on InfoQ, I can't believe this article got passed the editors.
-
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. -
if that can't be REST, then why include @QueryParam in JAX-RS
-
Craig - note that it is *not* called @MethodParam! Tunneling an operation through a URI parameter violates REST's self descriptive messages constraint. For example, if you do POST /service/getCurrentTemperature no cache could ever know it could cache the response. If you do GET /service/deleteAccount?id=33 and a robot comes along the link it will likely delete the account.
-
Jan - agreed. I was referring to something like http/www.mycompany.com/program/resource?id=xx
-
JAX-RS is not very RESTful... or better said, it allows too easily to implement just RPC style APIs over HTTP... I believe it's something to avoid if trying to get REST really understood & applied.
-
REST vs SOAP contest brings flashes of déjà vu.There are striking similarities between REST and assemblers as well as between REST and SQL. One can state that REST (as currently described) is the assembler for the web development and SOAP Web services are conceptualy close to 4GL programming languages. (By the way we can stretch our analogy a bit further and call SQL a “database assembler”. Then it becomes clear some systems will benefit from the trivial translation from the “web assembler” to the “database assembler”.) Limited verbs of the REST, assemblers and SQL were (and are) staples of existence in many areas. They restrict programming verbs to the "lowest common denominator" and promote simplicity (“the lowest”)and interoperability (“common”). However assemblers, sql and REST are hardly the best choice to abstract non trivial systems as they resist to the changes (lack of flexibility), rich compositions (lack of variation) and abstractions (lack of metaphor). From another side SOAP allows for more flexiblity at the price of complexity and run time overhead. 4GL's suplanted assemblers only when they could provide rich libraries for the standard operations and operating systems (programmiing ecosystems) could allow for the standard programming extensions-bridges (aka drivers). At this moment Web ecosystem has not much standard extension tools to accomodate SOAP integration and Web Service standard taxomonies (inspite of all SOA efforts)are still in their infancy. That is why REST and SOAP most likely will co-exist for a while and many systems will use a hybrid approach.
-
It does not make sense to compare ReST and SOAP - ReST is an architectual style, SOAP is a kind of RPC. Apples and oranges.
-
Hi Kim,
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 -:) -
I can't agree more with Jan on this. SOAP tunnels XML RPC calls via whatever protocol you send it over.
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. -
ditto... this is weak at best...
-
John, REST is an architectural style, not an implementation. HTTP just happens to be designed under such style, or has been the implementation from which REST was recognised.
21 comments
Watch Thread Reply