Web Things, by Mark Baker

Google is looking to expand the GMail beta. My old buddy Nelson hooked me up with an account last week, so now it’s my turn; I’ve got two invites to pass along. Who wants one?

Hmm, these Grand Central people seem to know what they’re talking about. I bet that has something to do with their EDI/EDI++ focus, rather than being a pure Web services play.
(link) [Mark Baker's Bookmarks]

Here come the APIs! Run away!
(link) [Mark Baker's Bookmarks]

He writes;

Per my earlier note, I have evaluated my feelings on the units of REST:

and goes on to “support” or “strongly support” all of the high level mandatory constraints of REST.

He also offered some very insightful observations on some of the differences between REST and Web architecture;

REST is a single candidate architecture. And an architecture must be evaluated on the whole, rather than the individual parts. Fielding does a great job of stating that every decision in the candidate architecture has trade-offs. He further identifies the applicability of the architecture (distributed systems, system ‘feels’ stateless, desire to scale, desire to evolve, etc.) Like all candidate architectures, one can only evaluate the architecture against a problem that you are trying to solve. REST by itself can not be evaluated, only evaluated as a candidate solution to a pre-identified problem.

Yes, exactly. Which begs the million dollar question; do you think it applies to machine to machine integration problems? If so, then I’d say that makes you a RESTafarian. Understanding the domain of applicability of an architectural style is very important; it’s not enough to believe, say, that “REST is great when you’re building Web apps for humans”; you’ve got to be able to see beyond that. At least IMHO, since I coined the term “RESTafarian” 8-) (which I’m sure I’ll regret at some point 8-)

What was interesting to me was the lack of association between REST and HTTP, or more precisely the ‘verbs’ of HTTP. Instead, Fielding places significant attention on the need to use Resources (think URI), Self Descriptive Messages (think XML), but does imply that a generic interface is required. Somehow… I find myself agreeing with Fielding but disagreeing with many RESTifarians (I’m not sure how this is possible). Fielding suggests a “a uniform interface between components “, however he never mandates what that interface should be – only stating the characteristics.

Modulo the “think XML” bit, yep. But this is actually one of my very few beefs with REST; the methods do matter. Roy and I talked about this (darn, can’t find the message in rest-discuss); that there should only be one “get me the state of this resource” method. He made some comment about how he didn’t want to list the obvious constraints. But as I’ve discussed, I think that’s quite non-obvious to a lot of smart folk.

However, I find significant ‘folklore’ stating that the interface is, “…defined completely and solely by the specified semantics of HTTP, i.e. GET / PUT / POST, etc.” (Jeff Bone) He continues to argue, “*there are no applications you can think of which cannot be made to fit into the GET / PUT / POST / resources / representations model of the world!*” The only issue I have is his term “made to fit” – meaning, what was the price of ‘making something fit’?

Very much agreed. Jeff sounds like he’s talking about GET/PUT/POST/etc.. as a 100% solution, but I think it’s more like a 97% solution, at least for “loosely coupled, document exchange” style solutions. As I mentioned to Jeff offline, in all my experiences with HTTP, only once have I ever had to use an operation other than GET, PUT, POST, or DELETE (or MONITOR) in order to get something done in a reasonably efficient way; that was to basically implement the functionality of a SQL UPDATE over a large set of resources (a PUT to each resource would have been prohibitively expensive).

Welcome (back!), Mike Dierken, fellow REST enthusiast. Subscribed!
(link) [Mark Baker's Bookmarks]

In response to my suggestion that he was on the road towards Web enlightment, Jeff Schneider asks;

Perhaps if one of the REST supporters would give me the discrete rules for REST, I could more clearly state my opinion.

To quickly answer that question, the “discrete rules for REST” are its constraints. You need only read Roy’s definition of REST to discover those, things like statelessness, resource identification, self-description, etc…

But I wasn’t suggesting you were a RESTafarian, only that you’re asking the right questions that, in my experience, lead to REST/Web enlightenment.

What do getStockQuote and getInvoice have in common? “get”. Can I use getStockQuote to return real time as well as delayed stock quotes? Duh, of course, I don’t need getRealtimeStockQuote and getDelayedStockQuote for that. So why can’t “get” be used to return stock quotes and invoices?

Jeff Schneider on the road to Web/REST enlightenment. GET, PUT, and POST are, in my experience, most of what you need in a verb set.
(link) [Mark Baker's Bookmarks]

Best of luck, Phil!! It seems we’re in similar boats; looking for something that “grips” us, a thing or two of our own on the side. The difference is, it seems, that there’s no way in hell that I would go back to school. YMMV. 8-)
(link) [Mark Baker's Bookmarks]

“Queries expressible as URLs. (straw poll: yes 9, no: 1)” Yeah!! But who’s the smart ass? 8-)
(link) [Mark Baker's Bookmarks]

I’ve wondered before where exactly Tim Bray stands on Web services. Now I know.

I agree with him more than I disagree, but there’s something I very strongly disagree with him about. Where I do agree with him is in the need for simplicity; things have gotten totally out of control, and we need to fall back to what we know works.

Where I disagree with him, is where he says that certain technologies - XML, URIs, HTTP, SOAP, and WSDL – work today, because he’s seen them work. I don’t personally think seeing one, two, or even a handful of working examples is sufficient. I want to see rabid success be a requirement for admittance to that list. So, IMO, the list should be XML, URIs, and HTTP.

I would really like to understand Tim’s support for WSDL. To me, if you think WSDL is a good idea (at least in its current form viz a viz WSDL 1.1 and WSDL 2.0), then you necessarily believe that state transfer, and, well, the Web itself, is somehow an insufficient basis for large scale distributed computing. I know Tim’s an absolute Web fanatic, which is why I’m at a loss to explain it.