JAOO, REST and a Fine Cup of Coffee
October 3rd, 2008 | Published in Events, REST by Ian Robinson
JAOO Aarhus 2008
I’ve just come back from JAOO Aarhus 2008, where I was presenting on “RESTful Enterprise Development” in Stefan Tilkov’s REST track. An anodyne title, I know, but in reality a straightforward case study illustrating how Atom and AtomPub are being used to implement an event-driven, business-service-oriented solution for a large entertainment and communications company. You can catch the talk again at the London Enterprise Web Conference in October and at QCon in San Francisco in November.
The other two speakers in the track, Stefan Tilkov and Arjen Poutsma, nicely advanced the conversation beyond the usual REST 101: Stefan with a concise, highly illustrative set of REST patterns and anti-patterns; Arjen with a preview of the forthcoming REST features in Spring 3.0, including first-class support for ETag filters and an API for the much-neglected REST client. Elsewhere the conversation touched on using the links embedded in representations to advance an application protocol: again, a welcome step forward from the naive misrepresentation of REST as a chatty, CRUDish interface on top of a data store.
That said, I don’t think any of us really nailed the “hypermedia and application state” subject; which is a shame, given that the day before, Gregor Hohpe had reintroduced his “Your Coffee Shop Doesn’t Use Two-Phase Commit” article to illustrate how simple business protocols – retry, compensate, throw away – are used in real-world business activities to advance the participants towards a successful outcome. A nicely self-contained, quirky example of application state: ripe, you might think, for casting in a RESTful light.
Which is exactly what Jim Webber, Savas Parastatidis and I have done…
How to GET a Cup of Coffee
Available now on InfoQ, “How to GET a Cup of Coffee” takes Gregor’s Starbucks example and runs it through a Web-friendly (that is, RESTish) state machine. Along the way, we take a potted look at using response codes for coordination, ETags for consistency, and caching for scalability and resiliency.
I’m really proud of the article: I don’t think there’s anything else out there that really deals with the topic in this way. Take a look and let us know what you think.