Web Things, by Mark Baker

Via Jim Webber, a pointer to Matt Garland’s thoughts on “processThis”.

Jim comments, saying this is “how Web Services should be”. But I don’t think Matt’s example is a good one, because it doesn’t use processThis semantics as we’ve discussed them to mean.

Matt writes;

I want to find some light reading for my upcoming vacation. I send a message to BookMonger, Inc. requesting books on Web Services. Let’s say that is a TopicSearch message. BookMonger returns me a TopicSearchResult message with some titles, descriptions, prices, etc.

If you do queries that way, then you’re no longer using processThis semantics, because there is an expectation that submitting a particular document type will result in a response which represents the results of that submission. That goes beyond the meaning of processThis, where a result of “Ok” would suffice as a response, indicating that the document was successfully processed. There is actually no way to obtain query results as response messages using only processThis; you need additional semantics.

This is where GET comes in. Just as processThis/POST provides uniform data submission semantics, GET provides a uniform data request semantic.

You certainly could build a system with an architecture like the one that Jim’s talking about. I just think that the Web provides additional constraints on top which would yield a superior system. In particular, the Web would improve upon this approach by simplifying coordination (uniform submission and request semantics), providing an application model (hypermedia), improving visibility (one already-deployed shared abstraction, not an unbounded number of still-to-be-deployed ones), and simplicity, primarily via the application model.