> I was attempting to make an analogy between the client's incarnation
> of the application and a state machine. In the linked email, Roy
> refers to the client's incarnation of the application as "hypermedia
Which Duncan called a "hypermedia landscape." I suppose "application
state" can be interpreted as "the current page" (so to speak, usually
more than one representation makes up the current steady-state), whereas
both Roy and Duncan are trying to make a point about other tabs the
user has open on the same site, plus the history contained within each.
OK, I get it now, so I suppose I take back my objection...
> Between requests, the client's (or user agent if you prefer)
Actually, this isn't a preference -- there's a reason for REST having
defined a more-explicit term. The default meaning of "client" in REST
is "client connector" which could be on a cache -- caches know nothing
of application states or hypermedia landscapes/workspaces, only which
representations map to what resources.
When we're talking about client-side issues which are relevant to both
intermediaries and user-agents, we say "client"; another term is
required for the component assembling multiple representations into
application states and acting on user input. Hence, "user-agent" --
very descriptively precise of exactly what's being discussed, while
deliberately allowing "client" to have the same meaning it does in
"client-server," for multiple components. An origin-server component
can have a client connector.
> hypermedia workspace is like a state machine's "current state". Then
> actions taken by the client/UserAgent via links are the state
Well, links or forms. Submitting a hypertext form is a user request
for a state transition, the semantics of which are described by the
method (your introductory post mistakenly lists methods as part of the
representation constraint, they're really part of the self-descriptive
messaging constraint; also, self-descriptiveness isn't simply headers,
as headers are part of the representation). The payload of PUT, PATCH
or POST requests are (not necessarily full) representations of user-
agent application state being transferred to the origin server, for the
purpose of manipulating one or more resources.
If you're looking for a state machine, it's found on the server -- each
resource is a state machine. REST applications aren't -- think of
manipulating a form. Each field, as it's altered, changes the state of
the application without changing any underlying resource states.
Background saves or user-initiated actions serve as input to one or
more state machine resources, each of which has an output which begins
with a status code. Altering forms isn't a state-machine interaction;
submitting forms and clicking links are, where resources are concerned.
The current state of the resource doesn't change when it's dereferenced.
The state of the resource may be changed by transferring a
representation of the resource's desired state. What goes on in user-
agents isn't a state machine, because the output isn't a function of
the input -- the result of clicking on a link is to transition from one
application state to another; however, what the user sees depends on
type and configuration of user-agent (or authentication, or a host of
other factors), where the same user generating the same input doesn't
get the same result from one client, or even one session, to the next.
Once you've coded a REST resource, the same input always yields the
same output (idempotent method or not), with certain exceptions like
503 errors. I've always considered resources to be Mealy Machines, or
at least such simplicity is my goal when designing resources.
"Beware deviating from the path of The Architectural Constraints!"
Disagree. You're suggesting there's some ideal ("The") set of
constraints (style). This POV flirts with purism, suggesting REST as
Maslow's hammer. The only thing to beware of, is Roy's wrath if you
apply the term REST to some other set of constraints... There's a
limited REST mismatch in my system where I've ignored a constraint and
don't intend to fix it. It's an optimization, so I don't consider it
some other style -- just REST with a small, identified mismatch. All
HTTP systems have REST mismatches, anyway.
REST may also be extended; see ARRESTED and CREST. Roy's thesis should
really be taken as a methodology for developing distributed software
architectures, with a tutorial (chapter 5). REST isn't a religion,
just a named set of constraints describing idealized behavior. Design
by constraint *is* a religion, one I'm happy to preach. There is no
best set of constraints, only the set of constraints best applied to the
system being designed -- this is the path from which one must not
Constraints are derived from the observable characteristics (pointed
arches, Internet scale) of existing systems. The natural scientist in
me loves it that constraints are like theories -- explanations of nature
(I consider the Internet a living, albeit non-sentient, phenomenon of
nature) derived through observation and experimentation (market research
of consumer preference qualifies, and results in the bell-bottom pantleg
constraint coming in and going out of style). The creative artist in me
loves it that constraints may be applied in myriad fashions evocative
of the same style.
Some gothic cathedrals merely *looked* like gothic cathedrals, but have
failed to stand the test of time; while others still stand, with only
intermittent (and mainly non-structural) restoration. Incorrect
curvature of the points of the arches, or flying buttresses insufficient
to the height of the walls, or foundations not dug deeply enough -- all
such deviation from these constraints of masonry led to the long-term
failure of some very pretty buildings, whereas other very pretty
buildings meeting these constraints remain in productive service.
Some romanesque cathedrals also still stand. That architectural style
imposed limits on the scalability of cathedral structures, so it was
*extended* by the gothic style. If the design goals of a cathedral
cannot be distinguished from those of the romanesque style, then the
choice of romanesque vs. gothic architecture is one of taste. If those
design goals exceed the scalability of romanesque architecture, the
choices include extending or innovating within some existing named set
of constraints, or devising a new set of constraints and bestowing a
name upon the resulting style.