Loading ...
Sorry, an error occurred while loading the content.

Re: [rest-discuss] client keeps its state

Expand Messages
  • Eric J. Bowman
    ... This thread needs a terminology scrub. In REST, the application is defined as what the user is trying to accomplish , and the user s agent is the
    Message 1 of 33 , Apr 4, 2010
      Guilherme Silveira wrote:
      > How should a client decide its next step?

      This thread needs a terminology scrub. In REST, the application is
      defined as "what the user is trying to accomplish", and the user's
      agent is the "client". The client never decides what to do next, only
      the user does. The client is there to carry out the user's orders.

      The "user" of course, is not required to be human. But, this thread is
      as clear as mud, because "user" and "user-agent" are being combined
      into "client". When I as a human am driving a REST application, I am
      not the "client" nor am I part of the "client component".

      As best I can tell, I'm the "user component" the client sees through a
      "middleware connector" just like BIND components interact with client,
      server and intermediary components through resolver (also middleware)
      connectors. I see a machine user the same way -- as a "user component".

      I think it would help the discussion of m2m interaction to enforce the
      distinction between "client" and "user". A machine user is trying to
      accomplish a set task, just like a human user. How the machine user
      utilizes the client component to accomplish its task is a discrete
      problem, separate from the problem of the client's application state.

      With a shopping-cart system, the human user is presented with a series
      of application steady-states. These steady-states contain many links
      that are of no interest to me if I'm trying to check out my cart. If
      my goal is to check out my cart, I only have interest in the specific
      state transitions presented which advance me towards that goal.

      The problem is, how does a machine user deduce which of the presented
      state-transition options will advance it towards its goal? This is a
      problem orthogonal to REST, which is not to say off-topic to rest-
      discuss. Once the client component arrives at the proper steady-state
      REST doesn't enter the equation again, until the user requests some
      transition to the next steady-state in their specific application.

      This is a "vocabulary problem". As we discussed here late last year,
      it would be nice if there existed some standardized RDFa and link
      relations to describe state transitions specific to checking out a
      shopping cart, and provide common markup for Name, CC#, sec code,
      billing/delivery address(es) and other standard form fields. Such
      efforts are, in fact, underway.

      It would then be trivial to write a machine agent capable of finding
      the best price on toilet tissue (etc.) every few months, and placing a
      resupply order on my behalf. This machine agent knows exactly how to
      fill out the forms and drive the shopping-cart application because it
      has knowledge of standard link relations, media types, and HTTP methods
      -- in addition to supplemental knowledge of the various domain-specific
      vocabularies it will encounter until some standard is arrived at, and
      of course specific knowledge about my brand, color, scent and pricing
      preferences, plus of course my billing and shipping information (which
      the merchant may also have stored as application state in the
      representation my agent retrieved).

      The GETting and POSTing of information using self-documenting HTML form
      interfaces is the purview of REST. How these application steady-states
      inform the user as to how to proceed towards various goals (each choice
      representing a different possible "application" in its own right), is
      opaque behind the Uniform Interface, just like system logic on the

      Informing human users is simple -- provided the system speaks their
      human vocabulary (English, Spanish etc.). Informing machine users how
      to drive the exact same application logic (series of forms in the
      checkout process, for example) a human uses, is a problem that needs to
      be addressed in markup, not over the wire -- IOW, the shopping-cart
      problem is best solved for m2m without creating any new media types.

      The middleware connector between the user-agent and user components
      could be called a "user connector" or an "agent connector", but I would
      not use both, as it would imply that there's some difference to REST
      whether data input is programmatic, or keyboard and/or mouse (etc.).
      The important notion is that "user" and "user-agent" are different
      components in a REST application.

      Keith already addressed the other common terminology problem -- there
      are both resource state and application state, and the two are not the
      same (even when they appear to be).

      To answer the OP, "So the client should always infer its next step only
      based on its current representation, media type and relations?"

      The server instructs the client, using common media types and link
      relations, how to derive and render a steady-state. This application
      steady-state may or may not be the same as the state of the resource
      indicated by the initially-dereferenced representation. This process
      is bound by REST constraints.

      (You won't see a full set of links on my demo unless your client
      processes the initially-dereferenced resource's representation through
      a linked XSLT stylesheet -- the rendered, CSS-styled result is the
      application steady-state, which is mashed up from multiple source
      documents dereferenced during XSLT processing -- if dereferenced
      directly, most of these source documents aren't containers, so the
      resulting application state would be identical to that resource's
      state -- communicated via the dereferenced representation -- for some
      unknown instance of time before or after the immediate present.)

      It's this derived application state that presents the client with one
      or more possible state transitions. The client presents the user with
      these options. The human user can track and evaluate whatever the heck
      it wants to, when deciding which state transition to pursue. Your AI
      user is equally at liberty in what it can evaluate when determining how
      to proceed -- the price of TP from different suppliers, for example.
      This process is unbound by any REST constraints.

    • Andrew Wahbe
      ... Yes I see how that s confusing. By client I mean the thing running the application -- perhaps distributed user-agent is the right terminology here.
      Message 33 of 33 , Apr 6, 2010
        On Tue, Apr 6, 2010 at 6:07 PM, Eric J. Bowman <eric@...> wrote:
        Andrew Wahbe wrote:
        > But from a REST perspective, you could think of them being part of a
        > single distributed client...

        Not sure what you mean.  In REST, "client" specifically means "client
        connector", so do you mean a single distributed client connector, or a
        single distributed user agent?  Or is it a single distributed user,
        driving numerous user agents (like Google driving googlebot)?

        Yes I see how that's confusing. By "client" I mean the "thing running the application" -- perhaps "distributed user-agent" is the right terminology here. Consider an application that consists of multiple hypermedia formats, could be VoiceXML + CCXML or Atom + HTML. It could be the case that the markup is processed by a single process or it could be that different processes are handling the individual markup languages and coordinating somehow. The server is just seeing the HTTP requests and shouldn't really care how the user agent is internally constructed. Of course as I mentioned cookies break this -- it's another way that they are not ideal. VoiceXML/CCXML systems can sometimes be broken into as many as 3 separate components all making requests related to a single application session: the CCXML processor, the VoiceXML processor and a speech processor (performing speech recognition and fetching grammar files). Some of the related protocols have mechanisms to try and coordinate cookies: e.g. http://tools.ietf.org/html/draft-ietf-speechsc-mrcpv2-20#section-6.2.15

        Anyways, it's just food for thought.

        Actually, at second glance, CCXML seems more akin to Xforms -- is it an
        MVC application the server transfers to the user agent?  MVC on the
        user agent is a powerful REST design pattern that can be adapted to


        That's maybe one way to think about it. It is a finite state machine that communicates via messages/events to resources in an underlying client platform. Events cause state transitions, transitions handlers can send messages back to the platform or place HTTP requests to transition to a new page (or do various other things). I see parallels between this model and an Ajax application -- which can be thought of as a state machine: each "view" is a different state often labelled with a URI fragment (e.g. #inbox in Gmail)

      Your message has been successfully submitted and would be delivered to recipients shortly.