Since the day in 2006 that our
dialogue
took place with an imaginary eBay Architect, he has been promoted to imaginary
Enterprise Architect in an investment bank! Convinced by the merits of REST, he took
his enthusiasm for it into his new job and embarked on architecting a trading system
using REST or ROA as an alternative to SOA.
Now, he hit upon a snag: he had a REST "bank server" generating bids on an instrument
and POSTing them into that instrument's REST "market server". But then he had two
copies of his bid! One held by the bank server on one URI, and the other in a "bid
collection" held by the market server's instrument - on another URI.
He asked himself: "Which URI is the real one? Which host 'owns' the bid? Is the market's
copy just a cache? If so, why does it have a new URI? Why doesn't the market host know
the URI of the bank's original bid? Why can't servers become clients and just GET the
data that their own data depends upon?" The server seemed to be dominating the
conversation, not letting its 'client' server have a say in things.
Our worried Enterprise Architect noticed that such Service-Orientation permeated REST
practice: there were "REST APIs" to Web sites, or "Web services" with a small 's'. Even
AtomPub had a "service document"! Some patterns, like AtomPub, offered just simple
read/write data services through the full HTTP method set. Some simply used such a
read/write interface as a wrapper around more complex service functions.
He wondered: "Where's the Web in REST integration? The Web works great without PUT and
DELETE: isn't using GET on its own RESTful enough?"
So, remembering something I said about "Symmetric REST", he contacted me again...
...