IRC Conversation on User, User Agent, Media Types, Application etc.

Currently I am trying to figure out the significance of the various aspects of a RESTful architecture with regard to modeling. Such aspects as user agent, media type, steady state, user, application, and application state. Tried to build-up an explanatory train of thought on that basis in an exchange with Philipp Meier on #rest IRC yesterday. It is the typical, hard to read, IRC conversation but you might find it useful nevertheless.

Steady-State

I have been meaning to write up for some time something about the notion of steady state. Now it ended up in a rest-duscuss posting.

Some references that I found insightful:

• Steady-State in Roy's dissertation


• Posting dealing with application entry points


• Web applications can have many entry points


• Steady-states are to be understood in isolation


• Steady-State, bookmarks, cool URIs(last two paragraphs)
  

Slightly related from this blog: In Fear of Sub Requests.

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.