REST is Kafkarchitecture

hello will.

On 2013-04-22 15:21 , Will Hartung wrote:
> The "Change of Address" transaction at the Post Office is a stateless
> transaction, because the form, when properly filled out, is all of the
> information that is necessary to perform the transaction. You can take
> that form to ANY Post Office and the System will act upon it
> appropriately. You don't have to do it from your original post office,
> from it's city, or state. Any Post Office in the system can handle that
> request. There are no prerequisites.
>
> All it requires is a properly filled out form. If the form is not valid,
> the System will reject the form. At which point you can go fix the form
> and start over (get back in line). Or you can come back tomorrow. Or you
> can mail it in. Or you can drive to Prudhoe Bay in Alaska and drop it
> off there. The end effect is the same, your address will be changed. The
> fact that you've tried before, and where you've tried before, has no
> bearing on the request itself, nor who you gave the request too.
>
> Of course the Post Office maintains, somewhere, somehow, the
> relationship between you and where you live. But that is not "state" in
> this context. I consider that the value of the resource. (To help
> disambiguate between the two in discussions.)

thanks for bringing up that example. i have decided for a while now that 
traditional (pre-electronic) forms-based business processes are *the* 
perfect example to explain everything there is to explain about REST. 
bureaucracy has always been about formalizing interactions, hiding 
implementations, and making all interactions self-contained. it can be a 
bit painful for clients ("but i just *told* you what i am asking 
about"), but it means that every office drone can go to lunch at any 
time. personally, i read kafka now as a description of a RESTful system, 
and how it perfectly hides everything that's going on inside.

for a little while, i was even tempted to write a book (or more 
modestly, start a site) that explains everything about REST with 19th 
century office stories. it would be a lot of fun, and probably much more 
useful than many of the over-abstract explanations. and of course there 
are limits in terms of form complexity and the number of workers you 
could implement, but that really doesn't take away the fact that REST 
simply defines the architectural style of bureaucracy (and i mean that 
in a flattering way).

here's a challenge: is there anything in REST that you think does not 
map fairly easily to that analogy? i'd be really curious to hear about 
what that might be.

thanks and cheers,

dret.