More on REST

Mark continued our conversation with a comment on my recent post. Here's the text:

Tim, REST doesn't constrain you to using HTTP, it only constrains you to using uniform operations. *Many* other protocols can be used in this fashion, including NNTP (which, FWIW, is where HTTP got its "POST" operation), FTP (notice how clicking an ftp URI behaves the same as an http URI?), SMTP. Some are a bit troublesome to use uniformly, such as POP3 since it's quite stateful. And some, such as
telnet, well, just forget about it. 8-) Said another way, REST constrains you to use all resources (no matter which URI scheme they may be identified with) as if an HTTP proxy were in front them.

Unfortunately, "input" and "output", as commonly understood (i.e. WSDL) aren't operations, e.g. "input" and "getStockQuote". FWIW, the "ProcessMessage" style, which isn't REST, also uses this architectural constraint. See the post and discussion here;

I guess I'm confused then. If REST is essentially the notion of uniform operations, I don't see that in conflict with what basic Web services do. There are two ways to look at a Web service interface as defined in WSDL. One is to say that all services have at most four operations: input, input/output, output, and output. The messages that flow back and forth are arguments to those operations. An input argument (an XML message) that is interpreted by the service, which responds with an output argument (another XML message). Not all services respond to the same set of input messages, somehow you have to know what to send (from WSDL). This strikes me as very similar to HTTP. All Web sites respond to HTTP GET. The browser sends an input argument (an URL and querystring) and the service produces an output argument (a data stream). Not all sites respond to the same set of URLs, somehow you have to send (from links in an initial stream downloaded to a browser).

The other way to look at a Web service interface as defined in WSDL is to say that it's really the operations named in the portType. In that case, you can think of a service interface as similar to a protocol for using TCP. The particular messages you send and what they mean vary from service to service, the same way they do with, say, FTP and Telnet. From this perspective, a WSDL interface represents a protocol that multiple services and clients share. Now I suppose one could argue that those WSDL interfaces interfaces aren't uniform in the sense of being used across the entire Internet, but does that matter? If I'm working on a system inside a company or with a set of business partners, isn't sharing with them sufficient to be considered both useful and successful? And of course we may yet see some standard interfaces develop that lot's of clients and services use to communicate.

I think a lot of the confusion about WS and REST comes from an expectation that the WS stack will define a single standard interface. The point of WS, however, is really to allow application developers to build the interfaces THEY need. Some of those will become standard, many will not. But that doesn't mean they won't have succeeded in solving their particular problem. In short, I don't think of the goals being very different, it seems more a matter of scope to me.