Monthly Archives: November 2002

Addressing and Methods; Two Peas in a Pod

Jon follows up his Groove/REST blog by quoting Paul and I and concluding that we are actually saying the same thing. This is a really important point, so let me emphasize it here. As I wrote privately to Jon;

If you choose your verbs such that each can be used on every identifiable thing, then you have no addressing problem.

The moment your interface includes a method which is not uniform to all things, then you lose something because some aspect of identification is removed from the identifier, and moved to the method. For example, see Dan Connolly’s report on the problems with WebDAV’s PROPFIND method, which can only be invoked on WebDAV properties. On the Web this is considered a major faux pas, but it’s commonplace – arguably a defining feature – of and with Web services.

Also, this is related to my post on generalization of application interfaces.

Groove gets a REST based Web services interface?

Jon Udell writes that Groove has a REST interface, which peaked my interest. We’re discussing it over on rest-discuss.

I’m very encouraged to hear about REST being considered a cool and useful thing, and thank Jon for pushing that position. But (you knew this was coming, didn’t you? 8-) it doesn’t sound like Groove has it quite right. The bit of Jon’s article that suggested this to me was this;

It’s all organized as a web of linked XML documents controlled by a handful of verbs such as Create, Read, Update, and Delete.

It is true that a pre-defined set of small methods will help the system immensely, because coordination costs are lowered, and visibility is increased to firewall administrators (at least when the specification of its semantics are specified in the open, or just standardized). But not every set of fixed methods means you have a RESTful interface. As I described on rest-discuss, the uniform interface constraint also has something to say about which methods you use. Specifically, it says that any method you use must be usable on all resources/objects/services/whatever. Like GET, PUT, POST, DELETE, LOCK, MOVE, COPY, etc..

It doesn’t sound like this would be that big a change for Groove if they’ve already got a CRUD interface, but the benefit is that you get all of HTTP’s other features and deployed support (e.g. Akamai) for free, plus any future extensions. RFC 2616 isn’t 420K in size for nothing, and you’re not going to ever be able to adequately replace it with a 5K WSDL file.

So this is quite encouraging, but let’s try to nip the “REST interface = any limited set of methods” misconception in the bud before it gets too wide spread.


I just realized that the best way to grab the WSDL of a service is probably via HTTP OPTIONS rather than HTTP GET. OPTIONS was designed to return information which describes the interface to a service. From RFC 2616;

The OPTIONS method represents a request for information about the communication options available on the request/response chain identified by the Request-URI. This method allows the client to determine the options and/or requirements associated with a resource, or the capabilities of a server, without implying a resource action or initiating a resource retrieval.

I mentioned this on www-ws-arch.