I’ve got to get more involved with Atom, if only so I get to admire wonderful design work such as this.
(link) [Mark Baker’s Bookmarks]

Yup. XAML too.
(link) [Mark Baker’s Bookmarks]

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.