London Geek Night
February 12th, 2010 | Published in Events, REST by Ian Robinson | 8 Comments
Updated The video of Thursday’s London Geek Night is now online. Thanks to Ikenna Okpala and Skills Matter for recording the event.
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.
Enforcing the protocol
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.
Resource design
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:
- Design applications in terms of application protocol state machines
- Implement them in terms of resource lifecycles
- Advertise/document them using media types, link relation values and HTTP idioms
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.
And finally…
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.