The Lurker

The lost art of argument

posted by ajf on 2006-12-06 at 12:13 pm

Kevin wrote yesterday about a post by Mark Baker which is purportedly about separation of concerns in the design of web services.

Baker's conclusion (to oversimplify) is that HTTP GET is a Good Thing. The problem with the article is not the conclusion; the problem is that the argument does not support the conclusion.

We can test WSDL's capacity to separate interface from implementation by asking the following question; can the implementation of a WSDL-described service vary arbitrarily without requiring a corresponding change in the interface? The answer is clearly no, as for any given WSDL document, it's quite trivial to identify a change in the implementation that would require a change in the interface. For example, if our interface included an operation for retrieving real time stock quotes - say, getRealtimeStockQuote() - then a change to an implementation of that operation to return delayed stock quotes would necessitate a change in the interface because clients would be assuming quotes were realtime, as that is what "getRealtimeStockQuote" would be documented to mean.

So, in fact, WSDL does *not* separate implementation from interface. Surprising, isn't it?

In a comment on Kevin's post, I called this the worst analogy in the history of mankind, because I felt the getRealtimeStockQuote() example was bad enough to warrant some serious hyperbole.

The most obvious problem is that the arbitrary change he describes does not have anything to do with "separating implementation from interface". For example, I (as the provider of this hypothetical service) could change the implementation by getting stock quote data from a different source, and that wouldn't require a change of interface. (An example of an interface which would require a change if I changed data supplier would be if the old source used their own proprietary identifiers for stocks. But stocks have universally recognised stock symbols, which is another reason the stock quote example is a terrible choice for Baker's argument.) I might discover that fetching the quote data from my supplier is slower than it should be, and rewrite my implementation to use a more efficient communications library. I might discover that my service is so popular that it's more cost effective to, rather than simply forwarding requests to my supplier, accept a live feed from that supplier and store the quotes myself, servicing queries by fetching from my own store instead. There are plenty of changes I can make to how my service is implemented without needing to change that interface.

None of these changes are anything like the change Baker proposes, because his is not a change of some implementation detail. He's changing the contract. Baker argues that the problem is that you've got a method called "getRealtimeStockQuote" but the quotes aren't real time, and that the solution is to call the method "get". Baker's question — can the implementation of a WSDL-described service vary arbitrarily without requiring a corresponding change in the interface? — is nonsense. To illustrate, suppose my evil twin implemented another real time quote service with a simple HTTP GET, and that you are using his service in your get rich quick scheme. Are you going to be any less pissed off with him than you were with me for giving you delayed quotes? The answer is clearly no.

The problem isn't that the name in the interface can contain obsolete information, nor is it that some changes in behaviour require a change of interface; the problem is that some bastard isn't giving you the service you were promised. If Baker wants to make REST accessible to a SOAP+WSDL audience, he's going to have to come up with an argument that means what he says it does.