February 20, 2006
@ 09:14 PM

Patrick Logan has a post on the recently re-ignited discussion on REST vs. SOAP entitled REST and SOAP where he writes

Update: Mike Champion makes an analogy between messaging technologies (SOAP/WSDL and HTTP) and road vehicle types (trucks and cars). Unfortunately this is an arbitrary analogy. That is, saying that SOAP/WSDL is best "to haul a lot of heavy stuff securely and reliably, use a truck" does not make it so. The question is how to make an objective determination.

Mike is fond of implying that you need to use WS-* if you want security and reliability while REST/POX is only good for simple scenarios. I agree with Patrick Logan that this seems to be an arbitrary determination not backed by empirical evidence. As an end user, the fact that my bank allows me to make financial transactions using REST (i.e. making withdrawals and transfers from their website) is one counter example to the argument that REST isn't good enough for secure and reliable transactions. If it is good enough for banks why isn't it good enough for us?

Of course, the bank's website is only the externally focused aspect of the service and they probably do use systems that ensure reliability and security internally that go beyond the capabilities of the Web's family of protocols and formats. However as someone who builds services that enable tens of millions of end users communicate with each other on a daily basis I find it hard to imagine how WS-* technologies would significanlty improve the situation for folks in my situation.

For example, take the post Clemens Vasters entitled The case of the missing "durable messaging" feature where he writes

I just got a comment from Oran about the lack of durable messaging in WCF and the need for a respective extensibility point. Well... the thing is: Durable messaging is there; use the MSMQ bindings. One of the obvious "problems" with durable messaging that's only based on WS-ReliableMessaging is that that spec (intentionally) does not make any assertions about the behavior of the respective endpoints.

There is no rule saying: "the received message MUST be written do disk". WS-ReliableMessaging is as reliable (and unreliable in case of very long-lasting network failures or an endpoint outright crashing) and plays the same role as TCP. The mapping is actually pretty straightforward like this: WS-Addressing = IP, WS-ReliableMessaging = TCP.

So if you do durable messaging on one end and the other end doesn't do it, the sum of the gained reliability doesn't add up to anything more than it was before.

The funny thing about Clemens's post is that scenarios like the hard drive of a server crashing are the exact kind of reliability issues that concern us in the services we build at MSN Windows Live. It's cool that specs like WS-ReliableMessaging allow me to specify semantics like AtMostOnce (messages must be delivered at most once or result in an error) and InOrder (messages must be delivered in the order they were sent) but this only scratches the surface of what it takes to build a reliable world class service. At best WS-* means you don't have to reinvent the building blocks when building a service that has some claims around reliability and security. However the specifications and tooling aren't mature yet. In the meantime, many of us have services to build.   

I tend to agree with Don's original point in his Pragmatics post. REST vs. SOAP is mainly about reach of services and not much else. If you know the target platform of the consumers of your service is going to be .NET or some other platform with rich WS-* support then you should use SOAP/WSDL/WS-*. On the other hand, if you can't guarantee the target platform of your customers then you should build a Plain Old XML over HTTP (POX/HTTP) or REST web service.


Categories: XML Web Services
Tracked by:
"WCF, WS-RM and Partial Trust" (Commonality) [Trackback]
"More on REST vs. SOAP" (Stefan Tilkov's Random Stuff) [Trackback]
http://www.ecyware.com/blog/PermaLink.aspx?guid=cac59f34-1e43-4c48-8fbb-0cdad0ce... [Pingback]
"It Takes a While to Sink in Sometimes" (Dare Obasanjo aka Carnage4Life) [Trackback]
"Complex Queries and REST" (Ebenezer Ikonne) [Trackback]
"Complex Queries and REST" (Ebenezer Ikonne) [Trackback]
http://www.winterdom.com/weblog/2006/02/21/WCFWSRMAndPartialTrust.aspx [Pingback]
http://jawf5j3.net/activities/sitemap1.html [Pingback]
http://tr5d5iu.net/01/sitemap1.html [Pingback]
http://yftbsy1.net/southwest/sitemap1.html [Pingback]
http://yftbsy1.net/cingular/sitemap1.html [Pingback]
http://weujmru.net/musicians/sitemap1.html [Pingback]
http://weujmru.net/groups/sitemap1.html [Pingback]
http://issl7ti.net/movies/sitemap1.html [Pingback]
http://tb9wlm3.net/07/index.html [Pingback]
http://mc4bmvg.net/04/index.html [Pingback]
http://kiva.startlogic.com/sitemap1.html [Pingback]
http://privet.150m.com [Pingback]
http://node22.myserverhosts.com/~boosters/ [Pingback]
http://fongyf6.net/aol/sitemap1.php [Pingback]
http://fongyf6.net/megaupload/sitemap1.php [Pingback]
http://restablog.dreamhosters.com/motorcycles/sitemap1.html [Pingback]
http://anubis.sslcatacombnetworking.com/~rocata/phones/sitemap1.html [Pingback]
http://host239.hostmonster.com/~blogford/sitemap2.html [Pingback]
http://host239.hostmonster.com/~blogford/sitemap1.html [Pingback]
http://gator413.hostgator.com/~digital/tax/sitemap1.html [Pingback]
http://fastblog.sc101.info/loan/sitemap1.html [Pingback]
http://fskh6vo.net/sitemap1.html [Pingback]
http://fwve5e4.net/cnn/sitemap1.php [Pingback]
http://rrvptrt.net/handbags/sitemap1.html [Pingback]
http://mwtobvc.net/02/index.html [Pingback]
http://bh1pwys.net/southwest/sitemap1.html [Pingback]
http://ujprjlw.net/california/sitemap1.html [Pingback]
http://box432.bluehost.com/~zbloginf/sitemap1.html [Pingback]
http://box432.bluehost.com/~zbloginf/sitemap2.html [Pingback]
http://gator442.hostgator.com/~hockteam/alaska/sitemap1.html [Pingback]

Tuesday, February 21, 2006 6:29:19 PM (GMT Standard Time, UTC+00:00)
Does your bank really use "REST" to do secure and reliable transactions, or does it tunnel a bunch of stuff over HTTP to exploit the Web infrastructure, but not the web "architecture" as people such as Mark Baker define it? I don't know. I will bet that they use all sorts of non-RESTfully correct stuff such as cookies, stateful sessions, backend application servers that maintain session state, and so on. Also, I'll bet that they don't use HTTP on the back end, but rather employ a bunch of message oriented middleware and databases (possibly stitched together with SOAP) to communicate between the enterprise sytems and the Web-exposed tier. I'm with Don Box -- I don't care one bit whether this is RESTful or not, just so long as it actually works.

The question the WS-* stuff addresses is moving all the work that sites have to do to to build reasonably secure and reliable Web applications out of the application layer and down into the infrastructure. Nobody is saying that it can't be done without WS-*, just that WS-* will allow people to build secure sites without a lot of exposed plumbing. I'm personally and professionally agnostic on whether it succeeds or not; I agree that it is an empirical question. I'd be happy to be convinced that XML+HTTP alone is all you need to build a secure and reliable financial app, but AFAIK your bank, eBay, Amazon, etc. have done a LOT of application-level work to make this happen.

Also, as the recent victim of identity theft, I'm not exactly in awe of the security of the online banking system :-(
Tuesday, February 21, 2006 7:15:00 PM (GMT Standard Time, UTC+00:00)
There are two scenarios here; inside the firewall and outside the firewall. Outside the firewall, my bank, eBay and Amazon are using the basic infrastructure of the Web (HTTP, SSL/TLS and HTML). I don't use a custom WS-* aware client to withdraw money from my bank or to buy books from Amazon. Now within the firewall, it is quite possible that all of these entities use WS-* in going about their business.

So the questions are (1.) When should I use WS-* for my services outside the firewall and (2.) When should I use WS-* for services inside the firewall. So far whenever I've seen you blog about this you've thrown out buzzwords like "secure" and "reliable" as rationale for when businesses should embrace WS-* without any serious discussion or technical evidence. For example, took me less than ten minutes of investigation to come to the conclusion that WS-* currently doesn't provide anything that meets the definition of "reliable" according to our business needs at MSN/Windows Live. You can look at http://blogs.msdn.com/shycohen/archive/2006/02/20/535717.aspx for more info on this if interested.
Tuesday, February 21, 2006 10:06:32 PM (GMT Standard Time, UTC+00:00)
"If you know the target platform of the consumers of your service is going to be .NET or some other platform with rich WS-* support then you should use SOAP/WSDL/WS-*. On the other hand, if you can't guarantee the target platform of your customers then you should build a Plain Old XML over HTTP (POX/HTTP) or REST web service."

This is the truest thing I have read about web services in a long while.

The major issue I see with POX and REST is that they are too conceptual. If I wanted my APIs to be RESTful, I'm still not really sure what I should do.
Wednesday, February 22, 2006 10:12:45 PM (GMT Standard Time, UTC+00:00)
Here's an example. 30Boxes just rolled out what looks like an easy to use RESTful API set:

But there appears to be little consistency with other similar types of API sets, specifically with respect to errors, data structures, authentication.
Comments are closed.