Re: REST is Kafkarchitecture

On Mon, Apr 22, 2013 at 7:06 PM, Erik Wilde <[email protected]> wrote:

> 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.

Oh, I agree about the analogy, though I haven't put enough thought in
to a REST idiom that doesn't fit.

However, I have another example to share.

This considers the use of well known entry points.

The simple example is you want to go to the Hall of Records (as we
call them here) and get a copy of your Birth Certificate.

You find the Hall of Records ("everyone know where that is"), and you
hit the information kiosk. There, they give you a pamphlet that says
"Hall of Records Offices for the year 2013". It tells you that Birth
Certificates are on the 3rd floor, Office 304. And off you go.

Next  year, you come back, being as you managed to lose it again, and
need a new copy. Instead of stopping at the info kiosk, you refer to
your pamphlet that you kept. Mind, it's not 2014. You go straight to
room 304 -- The Regional Planning office. Oops. But look, there's a
sign: "Birth Records moved to room 417" Success, off you go.

Two years later, we're back...and off we go to 417 -- The Probation
Office. Oh no! And ever worse, no sign! The office moved over a year
ago and the sign is only kept up for 6 months. Now you're stuck
walking back down to the info kiosk and starting over.

This is an example of using a well know entry point, the ability to
cache information, as well as specifying the Cache Expiration date.

If you have reasonable caching on your main entry points, then clients
can fetch the "directory" once, and rely on it internally to look up
addresses, effectively giving you the same benefit of bookmarking the
absolute end point, but with the consent of the service so that it is
free to remain nimble and move things as they see fit. Internally, you
client should perform the same task: "GET http://example.com/entry",
but your internal infrastructure should realize it's cached, and
already marshaled and simply return a copy of the internal form rather
than requesting it again. Speedy.

It works as a good solution to "why do I have to constantly ask for
the same information?". If it is, in fact, "the same information",
then the service "knows that" and can (should) tell you a valid
lifespan for that information. It's a contract between the service and
the clients. If the service refuses to commit to this information,
then they deserve to be hammered with redundant requests and emails
from clients that "their server is too slow". Fix it.

By the same token, if a service decides to change an internal service
address "suddenly", then it's the client that's breaking the contract
-- let them eat 404s.

But, in general, I do look at REST systems much like paper based
systems. And if you want to add Asynchronous aspects to the system,
then you consider those old days of stuffing notes in carriers and
shoving them in to vacuum tubes. There -- an async architecture :)

-- 
CONFIDENTIALITY NOTICE: The information contained in this electronic 
transmission may be confidential. If you are not an intended recipient, be 
aware that any disclosure, copying, distribution or use of the information 
contained in this transmission is prohibited and may be unlawful. If you 
have received this transmission in error, please notify us by email reply 
and then erase it from your computer system.