Thank you to everyone who came along to the London Geek Night last night. There were many good questions and comments throughout the evening. I didn’t respond to all of them satisfactorily at the time, so I thought I’d expand on a few of them here.
Alex Scordellis asked a very challenging question: how does the server prevent the client from “teleporting” to locations that aren’t immediately accessible from its current location? In other words, how do we stop the client jumping around the app, ignoring the advertised URIs, going off the rails, and interacting with resources in a way that contravenes the application protocol?
One solution to this problem is to use ephemeral URIs. Remember, other than the entry point URI, every URI the client encounters will have been minted by the server as it generates representations. By appending an expiry time, signed using a private key held only by the server, to each URI, we can ensure that each URI the client is given is valid only for a short period of time. Subbu Allamaraju and Mike Amundsen talk about ephemeral URIs in their forthcoming book, RESTful Web Services Cookbook. Amazon S3 offers the capability to sign URIs in just this fashion so as to limit access to resources.
Of course, this still leaves a short “teleport” window open, which the client can use to make multiple requests of a resource that it ought no longer access. To close this window, we might consider maintaining a secret resource access counter per ephemeral URI inside the server implementation. When the counter limit is reached, the server replies with 204 No Content. The only way for the client to access this resource again would be for it to play fair by the application protocol, navigating advertised transitions until it comes upon a representation containing a link (with new ephemeral URI) to the desired resource.
It can be argued that a GET that increments a secret counter associated with a resource (at an ephemeral URI) is no longer safe. Is the incrementing of a secret counter an unintended user-visible side-effect? The argument is played out in the comments to a post from Sam Ruby from 2002. Read the comments here and make up your own mind.
Adewale Oshineye asked how a design ought accommodate making small changes to large resources – is this necessarily an inefficient operation that requires the client to PUT the entire representation back? He also asked how one might support large batch operations in an efficient manner.
HTTP PATCH supplies one mechanism for dealing with partial updates, which fall under Adewale’s first question. Taken together, however, I feel Adewale’s questions lead us to reflect on the role of resource design in the overall design and implementation of a RESTful application. If we model our resources based simply on an understanding of business resources, we can end up with a resource landscape that’s not amenable to being manipulate din the way we require.
The first piece of advice usually given a would-be service designer is: identify your resources and assign them URIs. But this can all too easily lead us to identify only business resources – customer, product, order, etc – and equate these business resources with the resources our service exposes. But remember, the resources we deal with on the Web are information resources, which are somewhat more abstract than the business resources we typically capture in a domain model.
The design and implementation strategy that Jim, Savas and I recommend in REST in Practice is:
The transition from 1. to 2. here requires the service designer to decompose an application protocol into whatever information resources and information resource lifecycles are necessary to realise the protocol. The kinds of resources you identify using this approach may look a little different from the ones you would have identified had you taken a business domain resource approach.
I’m being a little vague here, but it’s a subject I plan to develop in more detail at QCon London.
In other comments, Bruce Durling pointed out I was mixing up 3rd edition D&D and 1st edition AD&D rules. Guilty as charged. -1 Credibility, no saving throw.
]]>On February 11th I’ll be presenting Hydras and Hypermedia at London Geek Night.
Do you know what your enterprise apps get up to in their time off? Fighting fantasy, pick-your-path, hypermedia-driven, RESTful Web application adventures – of course.
In this speculative dungeon delve I’ll show how we can use hypermedia-driven Web applications to model rich workflows. We’ll tackle the many-headed Hydra of HATEOAS, the “Hypermedia as the Engine of Application State” monster; level up through the Web services maturity heuristic; and meet the dwarves with grudges. On the way, we’ll learn how to model business processes as domain application protocols, implement them in terms of resource lifecycles, and advertise them using HTTP idioms, media types and link relation values.
atom:content element (enveloping).
A little while ago, Bill de hÓra expressed his preference for direct extension over enveloping. At its worst, enveloping results in near anaemic Atom entries, with very few of the Atom metadata elements put to good use, rightly prompting Bill’s question: “why bother using Atom at all?”
Like Bill, I’ve gone back and forth between these two options. At present, I’m inclined to use enveloping more than direct extension, but only if I can still put the Atom metadata to good use. If I find I’m having to fill out Atom metadata elements with lots of dummy information, just so that I can use Atom to transfer some opaque data between applications, I quickly turn to another format.
To my mind, Atom’s “meta-purpose” is to establish a domain processing context for some content. In AtomPub, Atom artefacts establish a publishing context for Web content. When used to establish this publishing context, the Atom artefacts are called collections and members, rather than feeds and entries.
I prefer not to extend Atom beyond the domain processing context I’m trying to model: instead, I push the thing to be processed down into the content. This allows for media type composition, whereby one media type processor hands off to another as it works its way through a representation. A reasonably “generic” Atom client can resurrect the domain processing context, which then remains in force whilst a specialized media type handler deals with the content (according to its media type).
In the past I’ve illustrated this point by showing how Atom feeds can be used to represent streams of events. The event metadata maps nicely to Atom metadata. The content itself contains a snapshot of some other resource’s state at the point the event occurred. In other words, the Atom metadata establishes an event-ish processing context for the content. When the client invokes a specialised handler for the content, it does so in the knowledge that its dealing with a representation of state at a particular point of time.
If I can’t separate a given problem into 1) an activity and accompanying processing context (e.g. “eventing”, “publishing”), and 2) the thing to be acted on, I’ll consider using something other than Atom.
]]>I used to introduce this topic with a quote from Beckett’s Unnameable – “You must go on, I can’t go on, I’ll go on” – which nicely sums up the situation I see many organisations facing today: burdened with a legacy systems estate, unable to stop the world, sorely in need of a change in strategy to face the future.
Based on case study material from the last few years, talk suggests some future proofing strategies that can arise out of an assessment of today’s business operations.
The First International Workshop on RESTful Design (WS-REST 2010) aims to provide a forum for discussion and dissemination of research on the emerging resource-oriented style of Web service design.
Over the past few years, several discussions between advocates of the two major architectural styles for designing and implementing Web services (the RPC/ESB-oriented approach and the resource-oriented approach) have been mainly held outside of the research and academic community, within dedicated mailing lists, forums and practitioner communities. The RESTful approach to Web services has also received a significant amount of attention from industry as indicated by the numerous technical books being published on the topic.
This first edition of WS-REST, co-located with the WWW2010 conference, aims at providing an academic forum for discussing current emerging research topics centered around the application of REST, as well as advanced application scenarios for building large scale distributed systems.
In addition to presentations on novel applications of RESTful Web services technologies, the workshop program will also include discussions on the limits of the applicability of the REST architectural style, as well as recent advances in research that aim at tackling new problems that may require to extend the basic REST architectural style. The organizers are seeking novel and original, high quality paper submissions on research contributions focusing on the following topics:
All workshop papers are peer-reviewed and accepted papers will be published as part of the ACM Digital Library. Two kinds of contributions are sought: short position papers (not to exceed 4 pages in ACM style format) describing particular challenges or experiences relevant to the scope of the workshop, and full research papers (not to exceed 8 pages in the ACM style format) describing novel solutions to relevant problems. Technology demonstrations are particularly welcome, and we encourage authors to focus on “lessons learned” rather than describing an implementation.
Papers must be submitted electronically in PDF format. Submit at the WS-REST 2010 EasyChair installation.
Also as part of QCon, I gave a talk, Beginning an SOA Initiative, the slides of which can be downloaded here.
Jim and I will be giving the REST tutorial at QCon London next year. We’re already planning plenty of changes so as to make it a little more hands-on and practical.
]]>At other times in the week you’ll find me hanging around the ThoughtWorks booth, where besides an informal chat, you can schedule a 30-minute one-on-one meeting with one of the many ThoughtWorks consultants attending the conference.
Photo taken from ElDave’s Flickr stream under the Creative Commons licence
]]>The session will be on Live Meeting, at http://snipr.com/virtualaltnet.
Please join us on Monday, times below:
<preceding>http://iansrobinson.com/0F449B535C2C</preceding>
<following>http://iansrobinson.com/796DC49C644E</following>and
<link rel="http://iansrobinson.com/resources/link-relations/preceding" href="http://iansrobinson.com/0F449B535C2C"/>
<link rel="http://iansrobinson.com/resources/link-relations/following" href="http://iansrobinson.com/796DC49C644E"/>Functionally equivalent?
There are two separate concerns at play here: finding links, and understanding links. An application’s semantic space – the set of link relations it uses to annotate links – is extensible. Understanding targets an open set. The capability to find links, on the other hand, ought ideally target a closed set.
In Example 1, each element bears the weight of addressing both concerns. The ability to find links is pinned to an open set. In Example 2, by contrast, the link element belongs to a closed set, with the semantic variance broken out and herded into the rel attribute value. Much easier to find links belonging to Example 2 using an application-agnostic function, a LINQ for Links, as it were.
What happens when we extend an application’s semantic space?
<preceding>http://iansrobinson.com/0F449B535C2C</preceding>
<following>http://iansrobinson.com/796DC49C644E</following>
<all>http://iansrobinson.com/22F4D1881C36</all><link rel="http://iansrobinson.com/resources/link-relations/preceding" href="http://iansrobinson.com/0F449B535C2C"/>
<link rel="http://iansrobinson.com/resources/link-relations/following" href="http://iansrobinson.com/796DC49C644E"/>
<link rel="http://iansrobinson.com/resources/link-relations/all" href="http://iansrobinson.com/22F4D1881C36"/>A client of Example 3 will likely only be able to report: “foreign markup found.” A client of Example 4 will be able to recognize the new link, though not necessarily understand the new rel value.