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

Re: [rest-discuss] Re: Fledgling REST blogger looking for suggestions and feedback

Expand Messages
  • Glenn Block
    Jan, your knowledge of Roy s statements is just scary :p On Sat, Oct 30, 2010 at 12:03 PM, Jan Algermissen
    Message 1 of 11 , Oct 30, 2010
      Jan, your knowledge of Roy's statements is just scary :p

      On Sat, Oct 30, 2010 at 12:03 PM, 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


    • 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 2 of 11 , Nov 3, 2010
        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 3 of 11 , Nov 3, 2010
          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 4 of 11 , Nov 3, 2010
            "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 5 of 11 , Nov 3, 2010
              "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 6 of 11 , Nov 3, 2010
                "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 7 of 11 , Nov 4, 2010
                  +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.