mark nottingham

The ‘Web’ in Web Services

Monday, 27 September 2004

Web Services

I was very interested to see the reaction to WS-Transfer [PDF] over the last few days. While the SOAP Resource Representation Header had opprobrium heaped upon it (see previous discussion), Transfer passed by with nothing more than a few nodding heads and people saying “aha.”

That doesn’t make much sense to me; if anything, the Resource Representation Header tries to supplant MIME, not HTTP. Transfer, on the other hand, duplicates the semantics of HTTP in Web services.

Why would somebody want to do that?

As many have pointed out, Transfer seems like it’s a lot more trouble than it’s worth; running WS-Transfer on top of SOAP using XML on top of HTTP to get back to where you started wastes a lot of processor and bits on the wire. However, there are two areas that Web services have an advantage in — tool support and description — that might drive people towards Transfer.

Tool Support

The promise of Web services has always been that you’ll be able to pull some software tools out of the box and get full-functioned interoperability from the get go. That’s still pretty far away, but in the meantime, the tools are able to do a lot of cool things to make developers’ lives easier; just look at the newest from [insert major vendor of choice here] and you’ll see that it’s pretty much drag-and-drop, self-managing code that anybody can use.

This is the raison d’etre for Web services; the whole idea is to enable US$40,000-a-year programmers to design and implement their own network protocols. The tools make it possible to do that, guiding them down the right paths, and stopping them from doing stupid things (most of the time).

Contrast this with the state of the art in HTTP programming; the Java Servlet. Very developer-unfriendly, it encourages bad practice, by dispatching to the method instead of the URI. It’s so bad, in fact, that there is a huge variety of frameworks built on top of it, to hide it — and HTTP — from the developer. As a result, it’s difficult to use HTTP as a protocol if you’re not using it for serving HTML pages and forms (this has been discussed previously).

Furthermore, many (if not most) Web client and server libraries are deficient to brain dead when it comes to HTTP feature support. Whether it’s authentication, content-codings or caching, it’s difficult to configure them, and when you get them set up, the details usually aren’t implemented well (again, not exactly a new topic of discussion).

All of this makes it easy to understand why a novice (or even not-so-novice) developer will run screaming into the nice, safe, self-contained arms of an IDE that lets you build Web services.

Now, if tools can be built to make Web services easy, there’s no reason that usable, friendly tools for HTTP can’t be built as well. In fact, HTTP has an advantage; it’s already widely-deployed and proven.

Also, for Web services tools to offer a really good Transfer experience, they’ll need to be extended, because the basic abstraction of Web services using Transfer isn’t messages, it’s stateful resources.

Description

The other thing that supposedly differentiates Web services is the ability to describe a service, using WSDL. This is useful for configuring the tools, generating some code stubs, as well as for visualizing and agreeing upon the interactions that will take place.

There is no widely-recognized facility for the plain old Web (POW? Hmm), although I’ve mused on it before. That might be OK; upon closer examination, I don’t think the Web falls too far behind Web services here, because WSDL can’t describe stateful resources that well anyway.

How’s that? The Web, and specifically REST, thrives on identifiers; everything that’s interesting has its own URI. In WSDL, this is the “endpoint identifier,” and it’s a pretty sad thing; many Web services people go explicitly out of their way to avoid creating new endpoints. The Web, on the other hand, is all about having lots of endpoints, so that you can interact with anything that’s interesting using generic methods like GET, POST, PUT and DELETE.

WSDL doesn’t encourage this; each and every endpoint has to have its own binding, with its own concrete information about serializing the messages on the wire. When you’re putting a lot of application semantics into the methods, this isn’t a big deal, because you have one endpoint with a bunch of methods. However, when you want lots of endpoints with a few methods each, WSDL gets impractical and unmanageable pretty quickly.

A description format for Web resources would still be useful, but WSDL — as it sits today — isn’t that format. Previously, I’ve explored what would be a good description format, and it’s clear that there are lots of options, from something brand new to URISpace to extending WSDL with a new kind of Web-friendly binding.

I’m not yet sure what the best option is, but I’m building tools that will work with such a format, so I need something. My first thought is to leverage WSDL, but I wonder what the benefit of doing that is if no existing tools will support what I’m doing. It might be better to start fresh and come up with something optimal for the task, rather than trying to shove it into something designed for RPC and SOA.