January 20, 2006
@ 02:27 AM

Richard Searle has a blog post entitled The SOAP retrieval anti-pattern where he writes

I have seen systems that use SOAP based Web Services only to implement data retrievals.

The concept is to provide a standardized mechanism for external systems to retrieve data from some master system that controls the data of interest. This has value in that it enforces a decoupling from the master systems data model. It can also be easy to manage and control than the alternative to allowing the consuming systems to directly query the master systems database tables.
The selection of a SOAP interface over a RESTful interface is also questionable. The SOAP interface has a few (generally one) parameters and then returns a large object. Such an interface with a single parameter has a trivial representation as a GET. A multi-parameter call can also be trivial mapped if the parameters define a conceptual heirarchy (eg the ids of a company and one of its employees).

Such a GET interface avoids all the complexities of SOAP, WSDL, etc. AJAX and XForm clients can trivially and directly use the interface. A browser can use XSLT to provide a human readable representation.

Performance can easily be boosted by interposing a web cache. Such optimization would probably occur essentially automatically since any significant site would already have caching. Such caching can be further enhanced by using the HTTP header timestamps to compare against the updated timestamps in the master system tables.

I agree 100%, web services that use SOAP solely for data retrieval are usually a sign that the designers of the service need to get a clue when it comes to building distributed applications for the Web.

PS: I realize that my employer has been guilty of this in the past. In fact, we've been known to do this at MSN as well although at least we also provided RESTful interfaces to the service in that instance. ;)


Friday, January 20, 2006 2:53:30 AM (GMT Standard Time, UTC+00:00)
I agree, SOAP is overkill for pure data retrieval chores. But it has become sort of the ODBC/ADO/OLEDB of the internet for many developers: a standardized way to get at data that works against a bunch of different sources and back ends, if not optimally.

As in that world, there will probably always be developers who creatively optimize their architectures against the data source and take pride in performance, and those who use the generic least-common-denominator approach and deliver lesser performance but go home from work a little earlier.

Vive le difference!
Friday, January 20, 2006 9:47:51 AM (GMT Standard Time, UTC+00:00)
Common, it all depends. It might be a stupid idea in a lot of cases, but I can equally think of many situations where it makes perfect sense. If you have an internal backend system (ie not something that accessed directly from a browser) and are using SOAP for all your backend communication, why introduce another new protocol?!? If your services communicate all via SOAP, why introduce a second method just for large data retrieval? That will certainly not make your architecture simpler. Also, one might need some of the WS-* things. Sure, you can implement authentication with REST as well, but if everything is working well with SOAP and WS-Security, why not just stick with that? I feel your statement is WAY too general to make sense.
Friday, January 20, 2006 1:30:44 PM (GMT Standard Time, UTC+00:00)
Fashions change over time Dare, we used to be in a period where SOAP would be toolkit'd enough to be feasible for even public consumable web apps: It looks like those days are over.

As someone guilty of some of this anti-pattern in the past, I do agree with your main point, with your key phrase being 'building distributed applications for the *Web*'. A lot of the trap I (and others) fell into was that we made the cardinal sin (but, as always, with good intentions) of trying to 'homogenize' our line of business apps service/module/whatever comms stack onto a single protocol frame.

Where public consumption is likely, the simplest and existing form always seems to be the most effective. (Btw, if Avalon always had the 'View Source...' philosophical equivalent for the XAML then it *will* take off).

I think what's changed recently is that people are seeing the ‘cockroach HTTP’ as good thing rather than a bad - and are looking at alternatives to toolkits/technologies that rely on our anti-YAGNI tendencies that we all have when designing ‘big’.

- David
Friday, January 20, 2006 6:08:07 PM (GMT Standard Time, UTC+00:00)
SOAP is the wrong choice for your average web-based API suite that anticipates many users on many platforms.

SOAP is OK when there are fewer, more enterprise-like entities, primarily on .net and Java.
Friday, January 20, 2006 6:20:49 PM (GMT Standard Time, UTC+00:00)
I agree for "retrieval-only with simple arguments", but how frequently you see the "only" and "simple"? If you also need to interact with backend in more ways (such is post a complex update), it makes sense to do it over soap. Having REST for simple gets and SOAP for other things is more pain than just picking soap.
Friday, January 20, 2006 6:59:32 PM (GMT Standard Time, UTC+00:00)
> I agree for "retrieval-only with simple arguments", but how frequently you see the "only" and "simple"?

Given that RSS/Atom feeds are the most popular Web service on the planet and that search engines (i.e. only simple data retrieval) are one of the most popular end user applications on the Web, I'd say the answer is VERY FREQUENTLY.
Comments are closed.