February 13, 2010

Three Aspects of Steady-States

The #rest IRC channel (transcripts here and here) has recently become for me a valuable source for thought stimulation (come and visit). Yesterday we had a discussion regarding steady-states and the following observation has been made:

URIs refer to a certain application state; at least in the sense that one can use a URI to go back to a certain application state or that one can pass a URI to another party to bring this party into that application state.

However, 'that application state' (despite the notion that I can use the URI to get back to it) is not stable over time. The semantics of the mapping are, but the transitions available form that state can change. So, what is the significance of 'that application state'?

I have not figured that out yet, but here is a thought I had this morning as a reaction to the discussion:

A Web application comprises a state machine that can change over time. Each state (aka steady-state) of that state machine has three aspects:

  1. Its semantics (what the state means)

  2. The serialized state of the associated domain concept (e.g. order 10029)

  3. The outgoing transitions to other states

The first of the three is constrained to remain stable over time the other two vary depending on the state of the associated domain concept and the actual state machine the server intends to provide to (that particular) client.

UPDATE: It has come up in a number of places a notion of transient states or ephemeral URIs. As far as I understand the issue circles around the idea of giving distinct URIs to different states of application states. With this approach, an order in some 'review-pending' state would be represented by a different resource (and hence different URI) than the same order in the state 'shipment-initiated'. Please correct me, if I miss the point here.

My response to that can be found in this comment on Ian's blog.

I'd highly apprechiate if someone could shed more light on this issue. I think it is a deep one.


  1. Is the described state in the UPDATE edit maybe even a resource state, rather than an application state? I think this state is somehow independent of the user's application. I can imagene to retrieve the order state from multiple applications on different machines. Does this makes sense?

  2. Here are two definitions of application state from Roy T. Fielding:

    1. "the state of the user’s application of computing to a given task" (see http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven#comment-744) e.g., a user's application can be a Web browser and given task can be the rendering task of an Web page

    2. (preformatted)an application state is defined by:
    - its pending requests
    - the topology of connected components
    - the active requests on those connectors
    - the dataflow of representations in response to those requests
    - the processing of those representations as they are received by the user agent
    (see http://www.ics.uci.edu/~taylor/documents/2002-REST-TOIT.pdf)

    So I would conclide that an application state is not the current state of my shopping basket of an online shop. That's a resource state.

  3. Hi zazi,

    yes, it is resource state, but resources can be used to store application state (workspace state). I like the notion of 'workspace' Roy lays out here: http://lists.w3.org/Archives/Public/www-tag/2010Oct/0100.html

  4. Okay, then I would maybe still make a difference between 'application state' (as defined above) and 'workspace state' (as defined by Roy T. Fielding in the referenced mailing list thread).

    It's maybe somehow confusing how the term 'application' is used in both definitions.

    In "application state of a user agent", I would identify 'application'/'user agent' as the Web browser and hence 'application state' as the current state of that Web browser when processing requests etc. Here I would interpret it like the definitions given for 'application state' (see my 2nd comment on this post here).

    On the other side, I would interpret 'workspace state' as a state that belongs somehow to a Web application e.g., the state of the client side shopping cart (as mention in Roy T. Fieldings Email). Here 'application' is identified by 'Web application' e.g., Amazon as online shop.

    Does this make sense?

  5. 'Application' as I (and AFAIU Roy) use the term always refers to a particular running configuration of components (user agent, intermediaries and the origin servers that participate in the communication). The state of such an application is the client side workspace (the accumulated representations).

    I never use application to refer to the origin server component, e.g. Amazon shop. Only if a my user agent is communicating with Amazon an application is created.

    Does that make it clearer?


  6. And what is then a 'Web Application'? (btw, Roy T. Fielding used that term also in a response of your referenced mailing list thread, see http://lists.w3.org/Archives/Public/www-tag/2010Oct/0103.html)

  7. As I understand it, he means 'as the user agent is progressing thourgh the application', IOW: application == Web application.

    It might also be that he means 'as the user agent interacts with a service (== Web application)'.

    But I do not think the word has significance here.


  8. Yes, but in terms of the 'application state' definitions as quoted above, I would interpret it as following:

    application == user agent == Web browser != Web application. Web application is that thing that is somehow processed by the Web browser, not the browser itself.

    So, my interpretation is mainly in common with your second interpretation, which makes for me a huge difference what is meant by application and hence application state (vs. workspace statem, maybe), i.e. browser state vs. my current state of using that Web application.

  9. Take a look at slides 9-19 of http://www.slideshare.net/algermissen/res-tful-httppatternsantipatterns .
    This shows (hopefully) what I mean by 'application'. In the presentation I tried to start with a monolithic desktop app (consisting of components) and work the way up to a networked app (consisting of components connected over a network). See what you think.

  10. Ah, okay. I think I got that view now ;)

    However, it's really a bit tricky. Normally I would define an application as something that could do something or better that I could use for doing something.

    One would commonly type a Web browser as an application for mainly browsing web sites.

    One would maybe not so commonly type Amazon as an application for buying books. However, typing Amazon as a service or maybe web site for buying books might be broadly accepted.

    Anyway, in both cases I use these things (Web browser, Amazon) for doing something; that means, I use these applications.

    Thereby, e.g. a Web browser (a Web browser like application) is a prerequisite to use Amazon (maybe they have even a telephone hotline for ordering, but this shouldn't matter at the moment) to order a book. The important aspect is here that I use Amazon to order a book. So the use case is "order a book".

    The whole system that is important for exemplifying this task/use case (that maybe fits to your application definition) includes for this setting - me, who wants to order a book, - the web browser, as a prerequisite to communicate with Amazon, and - the Amazon web site (as Web application? - I would tend to agree here).

    So I interact (maybe even only literally viewed here) with Amazon to order a book. The general use case 'order a book', is now exemplified due a concrete task (which may even include several sub tasks e.g., book selection, ...).

    I can view the processing of that task via a state machine that has several processing states (e.g., book selected, ...). For that matter the whole general task / abstract state machine of that task can be described and stored.
    Based one these abstract states, I can describe each concrete state and store this description to make this state examplification persistent.

    So, I would tend to say that I always have a fixed concrete processing state at a given time, when I've decided at some time to start an order task. Everthing else should be without an interest at this high level, or?

    All in all, I utilized (the) Amazon (Web application) to do my concrete order and I always have a concrete processing state while doing this. This state should be independently of the concrete Web browser, which I'm using at the moment. I tend to say that such a state is one level (of abstraction) above the level where 'application state' lies. 'Application state' still seems to be something really client specific when I _use_ a Web application and 'steady state' has something to do with processing responses (from my understanding of the definitions from above).

    I can imagine to view the abstract concept 'book ordering' as a resource. I can also imagine to view the a particular "application" of that abstract concept as a resource. So that such a concrete instantiation can have a concrete processing state at a give time.
    However, I would prefer to use e.g. 'exemplification' instead of "application" as term for expressing this relation from abstraction to concretization to avoid confusion.