Web Things, by Mark Baker

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.

It’s about time. I wonder if they’re using Nutch? RDF Gateway could be integrated into Nutch as a content type handler, I would expect.
(link) [Mark Baker’s Bookmarks]

I’m so glad that we synchronized on the similarities between our two approaches. I’m just still not sure I understand his “coupling complaint” against REST.

He writes;

However, I believe that there is a danger by adopting the resource-oriented view that Mark’s approach suggests. Identifying a resource through a URI and applying the semantics of an HTTP verb on it (e.g., GET URI) is good for retrieving state, as the web demonstrates. My worry about this approach is that there is a coupling of an identifier (the URI), an interface (HTTP verbs), and the state on which these verbs operate. The approach may work for the web but as we attempt to build large-scale, distributed applications that do not involve the human factor, we may get complex networks of references between the states of resources containing references to other resources which, in turn, may lead to brittle applications. We use the same argument against the resource-oriented WS-RF approach, which of course introduces lifetime management, renewable references, etc. behaviours into the picture (borrowed from the distributed-objects world).

I’m trying hard to understand the coupling Savas speaks of there, and its purported problems. I’d say that there exists a weak form of coupling between the identifier and the interface via the URI scheme, and I consider that a feature; I don’t think you can late bind identifiers to representations – which provides a whole lot of simplicity and scalability – without it.

I’m not sure what he means by the coupling between the identifier, the interface, and “the state on which these verbs operate”. As I see it, even with a “processThis” approach, there’s that same form of coupling; some document is processed, and though its semantics are independent of previous documents (unlike WS-RF), the resulting state change in the server component is a function of the just-processed document, all previously processed documents, and any initial state that existed before that point. For example, if I was firing a bunch of documents to a processor which adds integers, then although the messages have identical semantics – “process this 1” – the state of the processor changes as a result of each one.

Savas, if that doesn’t describe what you’re talking about, can you elaborate please? Perhaps an example would help.

Document exchange is an application. Discuss.

Apparently, I’ve got a lot to learn about rules engines
(link) [Mark Baker’s Bookmarks]