Universal Interfaces

Saturday, April 21 2007 - blog

Stefan Tilkov:

This is probably the hardest thing to grasp about REST — the fact that any and all application semantics can be mapped to the uniform REST interface (the HTTP verbs) without introducing actions (operations/methods) into the URL, and without adding new verbs.

For that matter, any and all application semantics can be mapped into the uniform interface of "read", "write" and "move head".

But that doesn't mean I really want to write apps that way in either case...

It seems like quite a jump to take the general utility of a uniform interface and use that to imply the existence or definition of the uniform interface that precludes all others.

#1 Stefan Tilkov on 4.22.2007 at 7:06 AM

But did I actually make the claim you suggest I did? I don't think so. I believe we agree that all application semantics can be mapped to *any* uniform interface. As to alternatives, some are artificial IMO (like "processThis()" which is so generic it's cheating), others are pretty neat (like Linda-style TupleSpaces).What I do claim (altough not in the post you linked to) is that if application semantics have been mapped to the HTTP verbs, the resulting system is going to be superior to its WS-* counterpart.

#2 Frank Wilhoit on 4.25.2007 at 8:12 AM

Easy there!"Mapping" semantics to disk primitives is a reductio ad absurdum--obliteration by mapping.Mapping application semantics to the CRUD/HTTP verbs is potentially lossy but where it is extremely lossy you simply wouldn't do it.Thinking in terms of resources is a very powerful approach.If process instantiations can be resources, which can be initiated (PUT), cancelled (DELETE), queried for their status (GET), and nudged along to a new state of their lifecycle (POST), then it seems clear that enormous territories of things can be force-fit into this scheme but I will also take as a given, without asking for a pathological example, that some force-fits will be too extreme to be worthwhile.The real point is that, in order to point out the [numerous and very grave] objections to SOAP, it is not automatically necessary to put REST forward as if it were the only conceivable alternative.The overlap between the goodness of REST and the badness of SOAP is large but essentially fortuitous.