Re: [rest-discuss] client keeps its state
- Guilherme Silveira wrote:
>This thread needs a terminology scrub. In REST, the application is
> How should a client decide its next step?
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.
- On Tue, Apr 6, 2010 at 6:07 PM, Eric J. Bowman <eric@...> wrote:Andrew Wahbe wrote:> single distributed client...
> But from a REST perspective, you could think of them being part of a
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
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)