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

Re: Fledgling REST blogger looking for suggestions and feedback

Expand Messages
  • Ray
    Perhaps I should have been more clear in the post. I wasn t attempting to invent a new term for server states as Larry Masinter suggests in the linked email.
    Message 1 of 11 , Nov 3, 2010
    • 0 Attachment
      Perhaps I should have been more clear in the post. I wasn't attempting to invent a new term for server states as Larry Masinter suggests in the linked email.

      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 workspace".

      Between requests, the client's (or user agent if you prefer) hypermedia workspace is like a state machine's "current state". Then actions taken by the client/UserAgent via links are the state transitions.

      Am I understanding things poorly? Is that a bad analogy?

      ...or am I relating my understanding poorly?

      Perhaps I should revise the blog post to make it clear that the analogy to state machine is to be drawn to the user agent's hypermedia workspace? (not to a resource or to a representation)

      (sry I sent this twice Jan)

      --- In rest-discuss@yahoogroups.com, Jan Algermissen <algermissen1971@...> wrote:
      >
      >
      > On Oct 30, 2010, at 7:27 PM, Duncan wrote:
      >
      > >
      > > To me, Roy seems to be getting at more of a gestalt of application state. You can't map the current sampled state of a single resource directly into the whole current application state.
      >
      > Yep.
      >
      > http://lists.w3.org/Archives/Public/www-tag/2010Oct/0100.html
      >
      >
      > Jan
      >
      >
      > > And Roy doesn't mention state machines. There is no one current representation making up the single current application state, there are potentially scores of them, present and past. So any links are only state transitions in the sense that the overall application state can be progressed as a whole by /fetching more stuff/, perhaps in parallel.
      > >
      > > The point is that you get decoupling because, even though the hypermedia constrains and guides what is available at any time, it's up to the client (or, perhaps, the user driving that client if it's a browser) what it does to explore - perhaps in parallel - the hypermedia landscape before it, and in what order - perhaps back to previous places on that landscape. The current history, cache and rendered page (for a browser) are parts of the whole application state.
      > >
      > > In other words, don't forget the back button! There's not always a link for that in the hypermedia you're focusing on...!
      > >
      > > I'm sure others will chime in with their own interpretations... :-)
      > >
      > > (oh - smaller tip: don't say 'HATEOAS', say 'Hypermedia Constraint'! =0)
      > >
      > > Duncan
      > >
      > >
      > >
      > >
      > > ------------------------------------
      > >
      > > Yahoo! Groups Links
      > >
      > >
      > >
      >
    • Ray
      I ll revise; :) Better to acknowledge the existence of the HATEOAS term and map it to the preferred Hypermedia Constraint ?
      Message 2 of 11 , Nov 3, 2010
      • 0 Attachment
        I'll revise; :)

        Better to acknowledge the existence of the 'HATEOAS' term and map it to the preferred 'Hypermedia Constraint' ?

        ...or better to ignore the existence of the term HATEOAS?

        --- In rest-discuss@yahoogroups.com, Jan Algermissen <algermissen1971@...> wrote:
        >
        >
        > On Oct 30, 2010, at 7:27 PM, Duncan wrote:
        >
        > > (oh - smaller tip: don't say 'HATEOAS', say 'Hypermedia Constraint'! =0)
        >
        > +1, +1, +1, ...
        >
        > Jan
        >
      • Eric J. Bowman
        ... I m not a big fan of that term. I think it s more common, and understandable, to refer to application state (client) vs. resource state (server). Those
        Message 3 of 11 , Nov 3, 2010
        • 0 Attachment
          "Ray" wrote:
          >
          > 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
          > workspace".
          >

          I'm not a big fan of that term. I think it's more common, and
          understandable, to refer to application state (client) vs. resource
          state (server). Those learning REST typically conflate the two, or
          assume that a REST application is the server-side system rather than
          the user interface.

          -Eric
        • Eric J. Bowman
          ... +1 -Eric
          Message 4 of 11 , Nov 3, 2010
          • 0 Attachment
            "Ray" wrote:
            >
            > ...or better to ignore the existence of the term HATEOAS?
            >

            +1

            -Eric
          • Eric J. Bowman
            ... Which Duncan called a hypermedia landscape. I suppose application state can be interpreted as the current page (so to speak, usually more than one
            Message 5 of 11 , Nov 3, 2010
            • 0 Attachment
              "Ray" wrote:
              >
              > 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
              > workspace".
              >

              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
              > transitions.
              >

              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
              deviate.

              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.

              -Eric
            • Erlend Hamnaberg
              +1
              Message 6 of 11 , Nov 4, 2010
              • 0 Attachment
                +1

                On Wed, Nov 3, 2010 at 6:10 PM, Eric J. Bowman <eric@...> wrote:
                 

                "Ray" wrote:
                >
                > ...or better to ignore the existence of the term HATEOAS?
                >

                +1

                -Eric


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