More on GET

I've been thinking a ton about this lately. GET's value was further emphasized to me when I was helping debug a very distributed demo. In addition to everything else, using the browser as a "Okay, is this part working?" tool is unbelievably compelling.

I agree that the resource-level PUT/DELETE stuff is not compelling. I tend to think it has the same issues for coupling that using a SOAP "verb based" interface has. Put simply: the more complex you make the interaction between two parties to accomplish a task, the tighter you bind them together and the harder it is to change. Having an interaction based on getting, posting, and putting lots of resources to make a change could be just as bad as a SOAP interface that requires you to invoke methods in a certain order and certain data back and forth. In either case, if you change the interaction you break the client.

The solution is a minimal footprint interaction, like a coarse-grained document transfer via a pin-hole, a la' a Biztalk port. Exposing all your data via GET so anyone can read anything they want (modulo security concerns) and then providing controlled writes through pin-hole ports that consume documents and encapsulate the actual update process.

This reflects a model that we talked about years ago for XML processing: expose an XPathNavigator to get any data you want and then offer controlled methods to update state. I put that model into production in MTPS (MSDN2), and it worked great (at least I thought so, I can't speak for the people who own it now).

We'll be using this approach for the main cross-system interface in my project. I'll let you know how it works in a couple of months.

Tim-

"In either case, if you change the interaction you break the client."

You define the interaction as a state machine so at least it's consistent. But if you wants to ask something to do something, you gots to couple. It's about where you do it in the stack.

"The solution is a minimal footprint interaction, like a coarse-grained document transfer via a pin-hole, a la' a Biztalk port."

Unless modern BizTalk servers have gotten past the controller/endpoint idiom, I'm not so sure (I stopped looking a few years ago). All the addressing and good stuff is being done in the SOAP envelope and the endpoint is purely a pinhole - GET to an endpoint typically tells you 406, right? See HTTPLR for an example of a half-duplex alternative - the value add is that every exchange is addressable and therfor can be put under management. I wrote that at a time when BizTalk (200/2) was driving me insane.

The browser itself is already a great state machine in my opinion. Even if you dive into 'MDI' side of UI world, something it is not design for (trivial example:'always on top' pin, or better: data -><- presentation perf hit). You get a lot of plumbing for free, and a popular term.

Diverging, BizTalk, glad I never touched it and it might not be a (price) overkill for Accenture, Shell and whoever else.

On management in general, nothing related to BizTalk, centralised type of it adversly affects fine or coarse grained approaches the same, it is not desired; cache coherency is an easier problem to deal with.

"Diverging, BizTalk, glad I never touched it"

I'm not as hasty. The choreography/visual features I don't care about, but for cross-administration messaging, there isn't really anything else out there that does what it does at the pricepoint.

The case of the missing Business Intelligence Studio [Via: kevindente ] More on GET [Via: Don Box ]...

I&#8217;ve collected lots of somewhat REST-connected posts in the last two weeks, but somehow can&#8217;t seem to find the time to comment &#8230; so here&#8217;s a quick linkdump: Verbs and Interaction patterns, Benjamin Carlyle, including some interesting thoughts on a gateway approach between WS-* and REST Mark Nottingham on REST issues, real and imagined &#8212; good points, especially regarding URI...

Thanks