David Chappell


Get the Feed! Subscribe

SOAP vs. REST: Complements or Competitors?  
# Tuesday, April 07, 2009
ESRI, a leading firm in geographic information systems (GIS) software, invited me to keynote their developer conference last month. I spoke about SOAP and REST, something that's relevant to most people building software today.

ESRI has posted a slightly edited video of the talk, along with a PDF of the slides. There's a bit of ESRI-specific content, but for the most part, the presentation is a general look at SOAP and REST.

The talk runs for more than an hour, so here's the punchline: Exposing services RESTfully is a better choice in a majority of situations, especially over the Internet. SOAP and the WS-* technologies still have some role, however, particularly inside enterprises.

31 comments :: Post a Comment



If REST people tried to specify standards they would definitely end up with some RSDL and soon establish consortiums which would be very happy to create something like ROAP/RS_* specifications!

But a RESTafarian would likely argue that a standard interface description language ("RSDL") and standards for things like atomic transactions ("RS-*") aren't necessary. And for a large share of the things we use services for, I've come to believe that they're right.

REST is step back in the technology to year 1995. The better name for REST should be POH (Plain Old HTTP).

It's hard to disagree. A RESTafarian, though, would say that this is a good thing.

And much of the time, I think the RESTafarians are right about this. Newer technologies aren't always better.

Great Post !!!

Just marked this for the link of month list


Do you have any opinions of your own or are you just parroting what proponents of REST say?

REST is nice in that any HTTP enabled app can consume. No SOAP associated glass ceiling.

But REST is cumbersome to consume due to lack of definition, the HTTP response codes returned are coded ad-hoc per platform, and it lacks the security, reliability, and transactability of SOAP because it's been intentionally gimped to baseline HTTP as a means of compatibility. Sure you can roll your own version of message security by encrypting your payload but if you're going to do that why bother with REST at all?

REST proponents emphasize the advantages of the technology, which means that describing REST's benefits implies "parroting" these facts. REST certainly has drawbacks as well, as you point out. You might want to watch the video linked to in this post--I describe most of the REST challenges that you mention.

Making the REST/SOAP choice is an engineering decision, one with pros and cons on both sides. The best way to make a good decision is to understand the two options, then decide which is the best fit for the problem you're trying to solve.

Wow! What an excellent presentation! Love your presentation style, David!

I was trying to make a decision between SOAP and REST and your presentation answered all my questions and helped me make the choice. I am going with SOAP for my purposes! The excitement about the "simplicity" and "elegancy" of REST wasn't convincing for me. And the most critical argument for my decision was actually pointed out by someone in the Q&A session at the very end: REST requests are all based on URLs, and SSL doesn't encrypt URLs!!!!

So, unless I am willing to publicly expose the protocol, REST is a no go for me! Sounds like SOAP over SSL does a much better job securing the protocol even if I don't use any WS-* enhancements. Or am I missing something?

I'm glad the talk was useful for you--thanks for the kind words.

That last point isn't correct, however: SSL actually does encrypt URLs. I'm not sure what I was thinking when I agreed with the guy who made that statement, but whatever it was, I was wrong. URLs are written into Web server logs in cleartext, as I said, but if you can't trust your Web admin, you have more serious problems than this.

David, thank you for your reply!

First of all, the concern about sensitive data ending up in web server logs is not just a matter of trust in a server admin, but it might be (and I think should always be) a matter of company policy. Web-facing servers are often the first servers to get compromised!

But my main concern is actually about sending URLs in clear text over the Internet. Could you please clarify which portion of the URL from your own example “GET www.quickbank/Accounts/2” will be encrypted by SSL? My understanding is that the entire “www.quickbank/Accounts/2” URL (except for any parameters after a “?” if present) will be sent in clear text, exposing the protocol. Or am I wrong about that? I really hope I am wrong!

Not to take anything away from your excellent presentation, but I think the use of URLs/URIs and their encryption via SSL deserves further clarification. Because using different URLs for different resources is such a fundamental thing in REST and because Internet security is so important in today’s world. Exposing the protocol (or even names of its business objects) may not be a big concern for public web services (like Google or Yahoo), but it’s a critical concern for most of B2B applications.

I've checked this point with various security experts, and they all agree: If you're using SSL, everything sent over the TCP connection is encrypted, including the full URI, parameters, etc. This means that all of the REST protocol exchanges are safe from pyring eyes as they traverse the network.

It looks like the link to the ESRI video is broken. Any chance you could post it? I'd like to share the video with some people.


ESRI has taken the video down, it seems. I pinged them awhle ago about putting it back up, but nothing's happened yet. I'll ping them again.

I also would like to view the video. ESRI seems to have swept out their '09 conference content in preparation for '10. Maybe it could be posted to YouTube?

Good idea--I'll look into this.


Can I get the Video link.

Thanks in Advance

The link to the video has been fixed--it works again.

Well, i have got to say that you are doing a really good job. I do presentations once in a while (i'm a rookie) and all i can say is: when i grow up i want to be like you!

seriously now, it such a good material! thx!

Im curious why you say soap has a place "particularly inside enterprises"... is that just to make all the people in those enterprises feel good after burning their eyes out reading all that SOAP-spec-gook and implementing it? Or the folks who invested all that IT budget in SOAP-servers? just curious. as far as "definition", why do you need more than xsd? Cant you still use XSD to specify representations to be exchanged?

The main reason is that some of the things that SOAP and WS-* provide, such as broader security functionality and distributed transactions, are really useful for some enterprise apps. In fact, not having these things can sometimes be a showstopper.

Also, it's the vendors who implement the "SOAP-spec-gook", not people in enterprises. And there's commonly no extra charge for SOAP/WS-* implementations (such as Microsoft's WCF), so enterprises aren't investing IT budget in "SOAP-servers".

Finally, you certainly can use XSD to specify representations to be exchanged, as both REST and SOAP commonly do. WSDL lets you define more than this, though, and so allows auto-generating client proxies. Some developers like this, at least for some situations.


nice answers.

my reply:
distributed transactions? does the promise here *really* outweigh the light/quick integration of REST? not sure.

with auto-generation of clients comes more tightly coupled/brittle interfaces between distributed components. again, depends on what you've exeperienced.

you didnt cover things like ignoring all the http semantics to scale, like "last-updated, cache-contorl and etag". how many times do you want to answer the question "how much does widget X cost?" if it doesnt change, and you're always POSTing (per SOAP), you spend massive cycles treating static things as if they were dynamic.

anyway, im not trying to convince anyone who doesnt want to be convinced, but to call them "equal and up to the developer" without also mentioning these items I think sells REST short. apologize if this is in the video, i couldnt get the link to work.

one other thing. Security? REALLY tired of hearing this. if you can break 128-bit SSL, go steal credit cards from amazon. don't worry about my pissy-little-enterprise. gimme a break.

Sean, I'm guessing that you're not an enterprise developer. For enterprises, light and quick integration is often outweighed by secure and correct (i.e., transactional) integration. And the scalability that HTTP gives you via caching, etc. means much less on your own local network, where you've probably got both cycles and bandwidth to spare. (This is why ordinary RPC protocols are so commonly used inside enterprises--they work well.)

And about security: There's much more to effective security than encryption, an area where SOAP is no better than REST. In my experience, the most important thing that WS-Security offers that's tough to do with REST is multi-hop identity, i.e., the ability to securely convey a user's token through multiple HTTP hops. This is critical in some enterprise apps.

Not every app is an Internet app, and technologies that are great on the Internet aren't always best for enterprises. I do believe that REST is more often a better choice than SOAP/WS-*, but not always.


thanks for the feedback. the answer seems to be the perennial "it depends".
just a couple of points

1. http can be as "correct and transactional" as you need it to be.
2. scalability on a network certainly depends on size of the network in terms of traffic/etc. id argue that as the network usage goes up, the value of caching static or dynamic resources also does.
3. in my experience, rpc is used more becuase so many developers are used object oriented programming, and dont know http semantics or the protocol. it certainly has never had anything to do with bandwidth usage in FAVOR of soap.
4. agreed, security is much more than encryption. but brokering identity is being done successfully by twitter, facebook, google, and many other huge "enterprises". the concept of application plugins for facebook wouldnt be possible without a good federation strategy. choose what you will, but i'll take FBAuth, OAuth or plain-old-REST, or extend REST, way before I try to digest the SAML2.0 (as in guess you're hosed if you did SAML1.0 last year ;-) ) spec in its entirety.

either way, thanks for the great discussion and the great blog.

The answer to the "SOAP or REST?" question is "It depends"--I agree.

Some final responses:
1. HTTP by itself can't provide two-phase commit across distributed transactional resources, e.g., SQL Server and DB2. WS-AtomicTransaction, built on SOAP, can. While Internet apps generally don't need this kind of transactional reliability, enterprise apps sometimes do. The big enterprise vendors have built WS-AtomicTransaction support into their products, but there's no equivalent standard for doing this RESTfully.
2. More heavily loaded networks certainly do get more benefit from caching. But enterprise networks don't face loads that are anything like a popular Internet application. Given this, they commonly have plenty of spare capacity, and so caching is much less important.
3. Many developers like RPC because it's easy. One of the drawbacks of REST is that while it's conceptually simpler than SOAP/WS-*, it's actually more difficult for many developers since, as you imply, it frequently requires them to work directly with HTTP instead of a simple set of method calls.
4. Multi-hop identity isn't the same thing as identity federation, and it's not what I was referring to. WS-Security can (optionally) use SAML tokens (not the entire SAML protocol), and it defines a standard way to pass those tokens securely through multiple hops running SOAP/WS-* implementations from different vendors. I'm aware of no similar RESTful standard for doing this.

Sean, it's clear that you're an Internet-oriented developer, which is great. Yet I'd encourage you not to assume that because you don't commonly face certain problems, those problems don't exist. The people who defined SOAP/WS-* were quite enterprise-oriented, but they weren't stupid. Even though some of the problems these technologies address don't show up much on the Internet, they're nonetheless critically important in some situations.

some 'final' retorts
1 - ok. distributed 2-phase commit aside, albeit however frequent or infrequent, if you really tried, i think it could be modeled.
2 - ok, fair point.
3 - i think its short-sighted, when, no matter how big or small your app or enterprise, if your application is distributed and made up of services, you'd like to be loosely coupled. this is the main argument against rpc, and imho, cannot be addressed enough. this is probably the main argument against soap-rpc.

david- i think im more a "loosely coupled" developer than an "internet developer", per se. I like the fact that you model nouns and leverage existing verbs (uniform interface), without reinventing things. While you are able to produce some examples here where there are no equivalents in REST, id say that the frequency of things you cannot do in REST (in SOAP) is far less than the amount of things you *can* do in REST with a much more loosely coupled yet well defined system (I think you made the first point, but Id add the second). but as we said, "it depends". And if 2-phase distributed transactions and multi-hop identity is your thing, soap may just be your thing.

Awsome discussion :)

I learned a load from you two (Sean, David) today.


Great presentation! Really great!

And it's a fair conclusion that each of this web services should be used depending on the context!

I'm a web developer, and this days I work with a lot of REST services, but I believe that's more because of the web context!

I'm more of a SOAP guy, but I don't thing that's an universal solution, especially on the restful web of today.

About which is easier to implement, I think is about what is should do. If it's small, REST can be easier to do.


I loved your talk too. But ESRI seems to have taken it down. Is there anywhere else I can access it?

-Frank Hardisty

Sorry about that--the link is working again.


Link to video is not working for me.

ESRI seems to have taken it down again. I'm working on reposting it myself.

Post a Comment

<< Home