Pete Lacey’s Weblog

Dan Pritchett takes me to task for something I said in my infoQ interview. In particular, this:

The second reason is that web services are too tightly coupled. Each participant needs to know a great deal about each of the others: the service and operation names, the messages they exchange, the datatypes of the message elements, the security context, the messaging semantics, etc. Thusly are non-scalable (and again I don’t mean transactional scalability) systems designed. One could argue that WSDL and the WS-Policy family of specifications addresses all this, but that’s not what I mean. Whether the tool knows or the programmer knows, the point is that one side of the conversation possesses intimate knowledge of the other, and should either side change, everything breaks.

Dan says:

What Pete is calling coupling, I call interfaces. Short of some magic that nobody has yet to explain, software components that interact need to have a contract and both sides have to know the contract. The client may not know about every detail of the contact, but it does know about the parts it needs. This is true whether the contract is exposed in SOAP or REST. And yes Peter, REST also exposes contracts that the other side needs to know. Move your resource to a new URI and see what happens to the clients.

Now I don’t believe in magic either, of course. But what Dan misses in his analysis is the word “too.” Read what I wrote again; “web services are too tightly coupled.” Yes, a REST client needs to know certain things about a service. And, yes, you can break a client by changing some of these things. But the difference between REST and SOAP is the degree of coupling.

To take Dan’s example, what happens if I do move a resource to a new URI? Do the clients break? Not if they leverage a proper implementation of HTTP. If I move my service, I set up the old URI to simply return a 301-Moved Permanently response code and put the new URI of the service in the Location field. Furthermore, in a RESTful application, which I’m defining here as an application that exposes multiple related resources, it’s not the client’s responsibility to orchestrate among multiple resources. Instead the server should guide the client through the application by supplying it the available hypermedia links at any particular stage. A client, then, need only know a single URI, that of the application’s introspection document, in order to access all of the resources available.

As is well known, REST applications also constrain the operations that are available, whereas each and every web service ever written publishes a unique set of operations that the client must know and know how to orchestrate. In a perfect world (and I know it’s far from perfect), RESTful applications don’t even need to agree ahead of time on the resource representation, instead they negotiate which well-known media type will be exchanged via HTTP’s accept and Content-Type headers. Properly RESTful applications push all state out to the client, therefore reducing what the server needs to know about past interactions. REST has a cache constraint, as well, allowing the client or server to cache a response without the client application even being aware that a response was retrieved from cache. And, so long as transport level security is sufficient, a RESTful client does not need to know the security semantics of the service ahead of time either. Nor does it need to worry about breakage if GET, PUT, and DELETE are called over and over again; it knows these operations are idempotent. REST applications exchanging XML documents should not have to worry about the data types of the message’s elements and attributes. They shouldn’t care if elements they weren’t expecting suddenly appear in these messages either.

Aside: I am fully aware that much of the overly-tight coupling that is evident in web service systems is attributable to the tooling and not to the specifications. However, the practice of web services is such that one cannot reasonably divorce web services from the tools.

It’s all a matter of degree. The more things that can be universally agreed upon (i.e., standardized) up front and the more constraints that are placed on the system, the looser the coupling. In the web services world not even the transport is constrained. Not that REST is perfect, mind you: there are quite a few best practices that can be made more formal, but new standards that are themselves RESTful (e.g. APP) can feel free to introduce additional constraints, and the community should be working on such standards. As Andrew Townley put it recently:

If the hypermedia constructs being used to describe the interaction between the clients and servers are not rich enough to abstract these things so the client needs to know that it’s supposed to POST data to URI x rather than being able to simply traverse hypermedia provided by the server (meaning the operation, data and location are provided to the client in a way it can understand rather than having any of this hard-coded as client implementation logic), then the hypermedia application being used (and not the information service) has not been sufficiently defined.

Dan goes on to say that the contract between client and service extends beyond the call interface and into the realm of service level agreements (response time, availability, etc.). He further notes that neither SOAP nor REST address this formally. No argument here, both of these statements are very true. Whether or not SLAs need to be specified via some standard, I haven’t put much thought into. But certainly, if a client is dependent on a service, then the client should have a formal agreement from the service owner to honor agreed upon SLAs. Otherwise, the service owner might just pull a Google on you.