It’s just data

Hasty Generalizations

Jon Udell: It’s also true that, as Sam Ruby has elegantly shown, SOAP can be used in a RESTful way that does not markedly differ from any other kind of XML-over-HTTP scenario w/respect to payload, but that can inject various kinds of enterprisey bits into the header.  From that perspective I suspect that SOAP and RSWS wind up being roughly the same.

Only if you consider the Google maps interface of today and the MapQuest interface that existed at the time Google maps was introduced as being “roughly the same”.  I don’t.  The abstractions and patterns are different.  For example: where’s the toString in SOAP?

Also, please don’t confuse SOAP with WS-*, as this leads to hasty generalizations.

It is quite one thing to point out that REST, as described by Roy’s dissertation, does not prescribe where any given header is to be placed.  It is quite another to point at any one specification and say that it has a proven ability to scale to the enterprise levels and beyond.

In related news, I put some effort into Chapter 10 yesterday, and Leonard did me the favor of rewriting the introduction to this chapter.


“Only if you consider the Google maps interface of today and the MapQuest interface that existed at the time Google maps was introduced as being “roughly the same”.”

I like your point in the referenced post about how Google Maps “tiled the earth” to create “individually addressable, cacheable, and scalable web resources.”

Another kind of granular resource is a credit application. As also mentioned in a not-yet-approved comment at ongoing, this article talks about how RouteOne handles them.

In particular, it talks about how the agreement to tuck SAML assertions into SOAP headers makes it possible to satisfy a requirement to flow those credit applications through a security intermediary.

There is no such requirement for Google Maps. If there were, you’d have to either use or reinvent SAML and WS-Security. TN Subramaniam told me that he was in the process of reinventing those things when he gratefully discovered that he didn’t have to.

Posted by Jon Udell at

If there were, you’d have to either use or reinvent SAML and WS-Security.

Reinvent is a strong word.

One could say that soap:Header “reinvents” HTTP headers.  One could even take it upon yourself to rewrite such services as they could (and arguably should) have been designed in the first place.

Which is the reinvention?  I guess that depends on what argument you are trying to further.

Meanwhile, it will be interesting to follow CardSpace, OpenID, and SAML in the upcoming months and years.

Posted by Sam Ruby at

I might be mistaken, but I think the major difference between SOAP (with WSDL) and REST is that in WSDLs the target URI of the operation is hard-wired, it’s quite difficult to change it at run-time. Contrast with REST, where passing URIs is an explicit part of the model.

Of course, in a dynamic, distributed system, it’s quite nice if you can indeed talk about locations instead of abstracting them away.

Posted by Martin at

it’s quite difficult to change it at run-time

With the toolkits that I have used, it simply is one statement.  For example, with the generated proxies you get in C#, you can control the destination by setting the Url attribute.

But I agree with everything else.

Posted by Sam Ruby at

Add your comment