client keeps its state
- How should a client decide its next step? Looking at the mime type,
representation content and relations or is it ok for the client to
keep track of its path on its desired process (the one he expects
*all* servers to follow)?
It seems like the second one is not REST, is it correct? So the client
should always infer its next step only based on its current
representation, media type and relations?
Caelum | Ensino e Inovação
- 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)