London Geek Night

February 12th, 2010  |  Published in Events, REST by Ian Robinson  |  9 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:

  1. Design applications in terms of application protocol state machines
  2. Implement them in terms of resource lifecycles
  3. 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.

9 Comments  |  Atom   RSS 2.0   Email

Responses

  1. Robert Rees says:

    February 13th, 2010 at 3:14 pm (#)

    I think the teleporting issue came up during the Away Day talk questions and at that time people seemed to agree that the server was responsible for the validity of client-accessed resource.

    So if Wyatt Erp requests the URL of the entrance having gone down the steps the server should handle the situation appropriately, perhaps redirecting to the url of the “current” location.

    In the example of the basket ordering if someone accessed a URL for an earlier state you would want them to actually be directed to the last phase of ordering they were interacting with because the goal is normally to close the transaction and make the sale.

    Time locking the url seems more effort that its worth, particularly as the server already knows what locations are valid as “next” moves when it calculates the “north-south-east-west” directions for the response.

  2. Stacy says:

    February 14th, 2010 at 12:09 am (#)

    For the example of a basket I think the user should be able to use their back button (or their history) to move the transaction to an earlier state. I agree that it would be good usability to present the user with the option to jump to where they left off; but not to force them there. If a user navigated to an earlier state of their basket I think I’d display how the basket looked at that time, the past state of a resource could be a very handy thing to have around and the past is immutable.

    For the game it makes sense to me that the server have a user resource and use that to constrain the user to allowed actions, or more flexibly to provide a historical view when the user tries to teleport to an earlier state; instead of re-providing the user with the options available from the earlier state instead disable all but the option they took; you could even hand out the starting url of a completed game so that others could watch your performance (*)

    I think minimal constraints should be placed on how resources can be accessed: only those constraints needed to retain the semantics of the application, the more constraints the fewer unintended uses.

    Here are some interesting uses: As an employee I put some software items into a basket and hand it over to my boss to approve it, they do so by handing it over to accounts to pay for it. As a lecturer I create a basket of books that I recommended my students read and hand it out to them, each of my students amends their copy of the basket before paying, as a lecturer I also send the basket to the library, they examine their stock, amend the basket and order 10 copies of everything they don’t already have. As a returning lecturer I amend my course and my recommend reading basket and give out the new basket.

    (*) Is this effectively creating a set of log resources, i.e. a replacement for log files ?

  3. Ben Butler-Cole says:

    February 14th, 2010 at 10:24 pm (#)

    The distinction between designing services to expose notional business resources and designing them around a state machine reminds me of Greg Young’s view that IT (generally) has failed our customers because we’ve forced them into a data-centric rather than behaviour-centric viewpoint (because CRUD is easy, so that’s what we implement).

    I can’t find an exposition of his argument in text, but there is an interview with him at http://herdingcode.com/?p=189 which makes the point.

    Ben

  4. The Morning Brew - Chris Alcock » The Morning Brew #539 says:

    February 15th, 2010 at 8:37 am (#)

    […] London Geek Night – Ian Robinson shares the video from his ThoughtWorks London Geeknight talk last week, and follows on the discussion from a number of points raised during the session. […]

  5. This Week in REST – Volume 3 (Feb 8 2010 – Feb 14 2010) « This week in REST says:

    February 15th, 2010 at 9:25 am (#)

    […] should reflect resource state at a specified point in time. (By Herbert Van de Sompel) London Geek Night – Report on the London Geek Night held on Feb 11 (with video!) Common REST Mistakes – […]

  6. Jan Algermissen says:

    February 15th, 2010 at 10:26 am (#)

    Ian,

    regarding the notion of ‘ephemeral URIs’: We discussed a similar issue over on #rest IRC (see log starting at http://rest.hackyhack.net/2010-02-12.html#254/h254 and next day).

    I am having trouble to understand why a server should expose an application state that is only valid for a certain time in the first place? Especially since the state of the application state itself usually evolves over time ( http://www.nordsc.com/blog/?p=358 )

    If the client needs to have an expectation about the current state of a resource, I’d rather have the client include that expectation in its request so the server can check it and take appropriate action.

    Roy describes this in http://tech.groups.yahoo.com/group/rest-discuss/message/9805

    “Think of it instead as a series of individual POST requests that are
    building up a combined resource that will eventually be a savings
    account when finished. Each of those requests can include parameters
    that perform the same role as an ETag — basically, identifying the
    client’s view of the current state of the resource. Then, when a
    request is repeated or a state-change lost, the server would see
    that in the next request and tell the client to refresh its view
    of the form before continuing to the next step.”

    Could you help me understand what your hypermedia modeling approach is that leads you to exposing states that become invalid?

    Thanks,
    Jan

  7. iansrobinson says:

    February 15th, 2010 at 11:14 am (#)

    Hi Jan

    (Replies to other comments coming when I have a spare moment).

    I don’t expect servers to expose application state: application state isn’t really a concern of the server. Rather, the server manages resource state. The application protocol, and the corresponding application states that can be achieved when executing an instance of that protocol are decomposed at design time into a series of resources, with resource lifecycles and resource states. This allows the server to be stateless with regard to application state.

    In other words, a process model can be transformed into one or more resource lifecycle models. Orchestration servers, like BizTalk, manage the process model, and persist application state. This is not what I’m seeking to achieve. Rather, I’m seeking to remodel a process so that it can be described purely in terms of information resource lifecycles, and the rules (known only to the server) that govern the relationships between information resources.

    So I’m not trying to expose states that become invalid. Clients can and should include expectations in their requests, which the server asserts against the current state of an information resource, thereby determining whether the intention declared in the received representation is valid in the context of the current state of the resource (determining the current state of a resource may involve the server asserting any rules that relate this resource to others).

    The very specific issue on the night was: what can we do to prevent a (bad, naughty) client from going off track, and starting over again – that is, stepping outside the application protocol. Given that we’ve decomposed the application protocol wholly into information resources and resource lifecycles (the server doesn’t maintain a view of the protocol “as such”; it only knows about resources, resource lifecycles and the rules that govern the relationships between resources), the issue then becomes one of ensuring clients interact legitimately with the resources through which the protocol “effect” is realized.

    Kind regards

    ian

  8. Jan Algermissen says:

    February 15th, 2010 at 7:26 pm (#)

    Ian,

    thanks, that clears things up to a large extend.

    I like your ideas in the first half (resource lifecycle) and will see if I find the common ground with my thinking – seems very similar (to me now) and maybe we just use the terms differently.

    In the second half you are loosing me; I have a hunch why but can’t express that yet.

    Thanks,
    Jan

  9. Mohan Radhakrishnan says:

    August 29th, 2010 at 4:39 am (#)

    Is there a practical example of this ephemeral url ? We have a forgot password link that is sent in an email. This has a state attached to it which can go stale but that is the intention. So in this case there is no application authentication. The url hits the application without authentication and the state is checked to see if the request is coming after the limited number of days.

    Is this a valid use case ?