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.