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

client keeps its state

Expand Messages
  • Guilherme Silveira
    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
    Message 1 of 33 , Apr 3, 2010
      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?


      Guilherme Silveira
      Caelum | Ensino e Inovação
    • 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.