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.
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
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.