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

Re: Understanding Steady States

Expand Messages
  • wahbedahbe
    ... Another relevant Roy writing (wow this list feels like theological discussions referencing Bible passages sometimes!) is in section 6.3.4.2 of his thesis
    Message 1 of 27 , Jan 25, 2010
      --- In rest-discuss@yahoogroups.com, Jan Algermissen <algermissen1971@...> wrote:
      >
      >
      > On Jan 24, 2010, at 4:51 PM, Jan Algermissen wrote:
      >
      > >
      > > On Jan 24, 2010, at 4:46 PM, Mike Kelly wrote:
      > >
      > >> Jan Algermissen wrote:
      > >>> On Jan 24, 2010, at 2:07 PM, Mike Kelly wrote:
      > >>>
      > >>>
      > >>>> the only way for the client to understand the 'meaning' of its
      > >>>> current state is in the context of the application flow (i.e.
      > >>>> series of link relations) which led up to it.
      > >>>>
      > >>>
      > >>>
      > >>> Correct me, but this is exactly what REST prevents. A client can
      > >>> use the URI of any steady-state and just proceed through the
      > >>> application from that point on without the need for any knowledge
      > >>> about prior interactions. If it can't, the representation is just
      > >>> badly designed.
      > >>>
      > >>
      > >> Are we drawing a distinction here between steady-state and entry-
      > >> point?
      > >
      > > Hmm, IMHO each steady state is a potential entry point.
      >
      > I knew it wasn't my clever observation but that Roy wrote it
      > somewhere... here is the link:
      > <http://tech.groups.yahoo.com/group/rest-discuss/message/5841>
      >

      Another relevant Roy writing (wow this list feels like theological discussions referencing Bible passages sometimes!) is in section 6.3.4.2 of his thesis where he talks about cookies messing up the back button.

      Your application state machine should allow arbitrary jumps (via "typed in" urls, back buttons, etc.) and so that implies that the application state shouldn't depend on the path taken.

      At the same time I can think there is "client state" that is independent of "application state". For example, the size of the window in a browser, the content that an atompub client is trying to publish are some examples. This client state affects the execution of the application, combining with the application state to affect client behavior. e.g. the application could display differently depending on the window size or the atompub client could pick different feeds from the service doc based on client state.

      I think was is important is that the application state should never rely on the client state value. One possible approach to ensuring this is to enforce that the application state should never affect/change the client state, but I don't think this is necessary or realistic. For example, the content that a client is trying to publish might depend on something that it previously fetched. The HTML5 client-side SQL store is another example of mutable client state (I think).

      So I think that application state can effect the client state, but as long as your application states never depend on the client state, you can jump around to arbitrary application states without things breaking. This does constrain how you do things though, for example, you have to write your HTML5 application to not depend on the state of client-side SQL tables.

      I'm making up my own terminology here as I'm not aware of a precedent. And maybe, this "client state" is really part of the application state -- but that doesn't seem right to me and doesn't match my experience.
      Regards,

      Andrew
    • mike amundsen
      Andrew: I treat client state as volatile optional data - similar to cached data. IOW, I write my code to work w/ any existing client state if it s available
      Message 2 of 27 , Jan 25, 2010
        Andrew:

        I treat client state as volatile optional data - similar to cached
        data. IOW, I write my code to work w/ any existing client state if
        it's available and, if not, lead the client into creating the needed
        state to complete the operation.

        Shopping cart is an example. When I client visits a URI, the server
        might check to see if there is any client state data (stored
        selections in the cart) to display. If not, the client is offered the
        proper link(s) to create some cart data.

        If I have any multiple-step operations (ala "Wizard UI") I'll inspect
        the client state on each step to see where in the process they
        currently are. If no state is avail (or some of the data is missing or
        has expired), the client is directed to the proper URI (possibly the
        start URI) and led along as needed.

        If a client attempts a write operation on the server (POST/PUT)
        without the required client state data (missing or invalid state
        data), the client is given the appropriate response code and offered
        one or more URIs to help deliver the expected data before
        re-attempting the write operation.

        The "client state data" might be complete data on the client (for
        custom clients) or a cookie identifier/authentication identifier (for
        common Web browsers). In the case of common browsers, I store any
        complex client state data on the server as a user resource (instead of
        user-agent resource) to get around data storage limits in current
        browsers and make sure users can log in via different agents and still
        retrieve their data. Now that local data storage APIs are available
        for scripted browsers, I hope to move some of this data back to the
        client.

        All these examples might include an authenticate step, but that's
        treated as an additional layer on the set of state transitions.

        In my experience, adopting these patterns from the outset takes more
        implementation time, but results in a more stable and, in the long
        run, more adaptable application.

        mca
        http://amundsen.com/blog/




        On Mon, Jan 25, 2010 at 13:44, wahbedahbe <andrew.wahbe@...> wrote:
        >
        >
        > --- In rest-discuss@yahoogroups.com, Jan Algermissen <algermissen1971@...> wrote:
        >>
        >>
        >> On Jan 24, 2010, at 4:51 PM, Jan Algermissen wrote:
        >>
        >> >
        >> > On Jan 24, 2010, at 4:46 PM, Mike Kelly wrote:
        >> >
        >> >> Jan Algermissen wrote:
        >> >>> On Jan 24, 2010, at 2:07 PM, Mike Kelly wrote:
        >> >>>
        >> >>>
        >> >>>> the only way for the client to understand the 'meaning' of its
        >> >>>> current state is in the context of the application flow (i.e.
        >> >>>> series  of link relations) which led up to it.
        >> >>>>
        >> >>>
        >> >>>
        >> >>> Correct me, but this is exactly what REST prevents. A client can
        >> >>> use  the URI of any steady-state and just proceed through the
        >> >>> application  from that point on without the need for any knowledge
        >> >>> about prior  interactions. If it can't, the representation is just
        >> >>> badly designed.
        >> >>>
        >> >>
        >> >> Are we drawing a distinction here between steady-state and entry-
        >> >> point?
        >> >
        >> > Hmm, IMHO each steady state is a potential entry point.
        >>
        >> I knew it wasn't my clever observation but that Roy wrote it
        >> somewhere... here is the link:
        >> <http://tech.groups.yahoo.com/group/rest-discuss/message/5841>
        >>
        >
        > Another relevant Roy writing (wow this list feels like theological discussions referencing Bible passages sometimes!) is in section 6.3.4.2 of his thesis where he talks about cookies messing up the back button.
        >
        > Your application state machine should allow arbitrary jumps (via "typed in" urls, back buttons, etc.) and so that implies that the application state shouldn't depend on the path taken.
        >
        > At the same time I can think there is "client state" that is independent of "application state". For example, the size of the window in a browser, the content that an atompub client is trying to publish are some examples. This client state affects the execution of the application, combining with the application state to affect client behavior. e.g. the application could display differently depending on the window size or the atompub client could pick different feeds from the service doc based on client state.
        >
        > I think was is important is that the application state should never rely on the client state value. One possible approach to ensuring this is to enforce that the application state should never affect/change the client state, but I don't think this is necessary or realistic. For example, the content that a client is trying to publish might depend on something that it previously fetched. The HTML5 client-side SQL store is another example of mutable client state (I think).
        >
        > So I think that application state can effect the client state, but as long as your application states never depend on the client state, you can jump around to arbitrary application states without things breaking. This does constrain how you do things though, for example, you have to write your HTML5 application to not depend on the state of client-side SQL tables.
        >
        > I'm making up my own terminology here as I'm not aware of a precedent. And maybe, this "client state" is really part of the application state -- but that doesn't seem right to me and doesn't match my experience.
        > Regards,
        >
        > Andrew
        >
        >
        >
        > ------------------------------------
        >
        > Yahoo! Groups Links
        >
        >
        >
        >
      • Jan Algermissen
        ... Yes. It is (part of) the state of the state machine that is the client- side program (or the human user). The interesting aspect here is what the
        Message 3 of 27 , Jan 27, 2010
          On Jan 25, 2010, at 7:44 PM, wahbedahbe wrote:

          > At the same time I can think there is "client state" that is
          > independent of "application state".

          Yes. It is (part of) the state of the state machine that is the client-
          side program (or the human user). The interesting aspect here is what
          the appropriate programming model is for aligning the client side
          state machine and the user agent state machine (which is driven by the
          server).

          The situation is comparable to a program that is not promarily driven
          by a GUI but occasionally hands control over to a GUI event processing
          loop.

          Jan

          -----------------------------------
          Jan Algermissen, Consultant

          Mail: algermissen@...
          Blog: http://www.nordsc.com/blog/
          Work: http://www.nordsc.com/
          -----------------------------------
        • Mike Kelly
          ... I can t agree with that - and don t think the quote you dug up is referring to this specific issue. For a machine client, RESTing at a given steady state
          Message 4 of 27 , Feb 1, 2010
            Jan Algermissen wrote:
            > On Jan 24, 2010, at 4:46 PM, Mike Kelly wrote:
            >
            >
            >> Jan Algermissen wrote:
            >>
            >>> On Jan 24, 2010, at 2:07 PM, Mike Kelly wrote:
            >>>
            >>>
            >>>
            >>>> the only way for the client to understand the 'meaning' of its
            >>>> current state is in the context of the application flow (i.e.
            >>>> series of link relations) which led up to it.
            >>>>
            >>>>
            >>> Correct me, but this is exactly what REST prevents. A client can
            >>> use the URI of any steady-state and just proceed through the
            >>> application from that point on without the need for any knowledge
            >>> about prior interactions. If it can't, the representation is just
            >>> badly designed.
            >>>
            >>>
            >> Are we drawing a distinction here between steady-state and entry-
            >> point?
            >>
            >
            > Hmm, IMHO each steady state is a potential entry point.
            >

            I can't agree with that - and don't think the quote you dug up is
            referring to this specific issue.

            For a machine client, RESTing at a given steady state and establishing
            its 'meaning' is a much more delicate affair than for a human client. We
            have fuzzy methods of inference and contextualization with humans that
            we just don't have the luxury of with machines.

            I think we need to agree on the definition of 'meaning' in this
            context.. because, to me, it includes more than just the current set of
            available link relations, and since we're not supposed to type resources
            - the only approach I can see working is predefined application flows
            (which may or may not contain several 'steady states') driven by link
            relations.

            - Mike
          • Jan Algermissen
            ... Predefined application flows violate the hypermedia constraint and couple the server in a way that REST deliberately aims to avoid. As you know from my
            Message 5 of 27 , Feb 1, 2010
              On Feb 1, 2010, at 1:38 PM, Mike Kelly wrote:

              > I think we need to agree on the definition of 'meaning' in this
              > context.. because, to me, it includes more than just the current set of
              > available link relations, and since we're not supposed to type resources
              > - the only approach I can see working is predefined application flows

              Predefined application flows violate the hypermedia constraint and couple the server in a way that REST deliberately aims to avoid. As you know from my questions on this list around this issue I have been banging my head against that wall, but the more it hurt, the clearer the picture became (for me at least) :-)

              It is really as simple as this:

              o The client needs an understanding of the set of media types that the service uses, IOW, the set of types the client has to be able to deal with. (this is what I think makes up a service type for discovery and 'governance' purposes)

              o For any request the client sends it must expect any HTTP response code and a representation of any of the set of media types. It is completely up to the client to deal with whatever it receives. 4xx is not 'broken contract' but an *essential* part of the contract.

              o The server has the obligation to not lie about the links it sends, e.g. using <img src=""/> to point to an Atom feed can be considered a broken server

              o The server must keep resource sematics stable (and steady state (==bookmarkable) resources should be presistent)

              Bottom line: it is really about putting *all* change handling into the clients (and to actively expect change) to allow independent server evolution and avoid ned for communication between server and client owners.

              The funny thing for me was that, once actively accepting these consequences, it turns out there is really not so much that can change about a server given the above obligations. REST externalises everything about an API that *can* be kept stable and lets the client deal with the remaining instabilities.

              Jan


              > (which may or may not contain several 'steady states') driven by link
              > relations.

              -----------------------------------
              Jan Algermissen, Consultant

              Mail: algermissen@...
              Blog: http://www.nordsc.com/blog/
              Work: http://www.nordsc.com/
              -----------------------------------
            • Mike Kelly
              ... Predefined application flows like AtomPub violate the hypermedia constraint? ... I would choose to say set of representations over set of media types .
              Message 6 of 27 , Feb 1, 2010
                Jan Algermissen wrote:
                > On Feb 1, 2010, at 1:38 PM, Mike Kelly wrote:
                >
                >
                >> I think we need to agree on the definition of 'meaning' in this
                >> context.. because, to me, it includes more than just the current set of
                >> available link relations, and since we're not supposed to type resources
                >> - the only approach I can see working is predefined application flows
                >>
                >
                > Predefined application flows violate the hypermedia constraint and couple the server in a way that REST deliberately aims to avoid.
                >

                Predefined application flows like AtomPub violate the hypermedia constraint?

                > It is really as simple as this:
                >
                > o The client needs an understanding of the set of media types that the service uses, IOW, the set of types the client has to be able to deal with. (this is what I think makes up a service type for discovery and 'governance' purposes)
                >

                I would choose to say 'set of representations' over 'set of media
                types'. Those representations will define types of link relations, which
                in turn define the application flow(s). Over time - other links/flows
                can be added, resources moved, media-types added etc. This is what I
                have understood as evolveability aspect of REST wrt the hypertext
                constraint.

                >
                > The funny thing for me was that, once actively accepting these consequences, it turns out there is really not so much that can change about a server given the above obligations.

                Ok - are you saying this is a Good Thing?

                - Mike
              • Jan Algermissen
                ... Yes. Roy confirmed that (recent post on atom-protocol list) ... Not getting what you mean. You cannot specify the set of representations - they can cary at
                Message 7 of 27 , Feb 1, 2010
                  On Feb 1, 2010, at 2:54 PM, Mike Kelly wrote:

                  > Jan Algermissen wrote:
                  >> On Feb 1, 2010, at 1:38 PM, Mike Kelly wrote:
                  >>
                  >>
                  >>> I think we need to agree on the definition of 'meaning' in this
                  >>> context.. because, to me, it includes more than just the current set of
                  >>> available link relations, and since we're not supposed to type resources
                  >>> - the only approach I can see working is predefined application flows
                  >>>
                  >>
                  >> Predefined application flows violate the hypermedia constraint and couple the server in a way that REST deliberately aims to avoid.
                  >>
                  >
                  > Predefined application flows like AtomPub violate the hypermedia constraint?

                  Yes. Roy confirmed that (recent post on atom-protocol list)

                  >
                  >> It is really as simple as this:
                  >>
                  >> o The client needs an understanding of the set of media types that the service uses, IOW, the set of types the client has to be able to deal with. (this is what I think makes up a service type for discovery and 'governance' purposes)
                  >>
                  >
                  > I would choose to say 'set of representations' over 'set of media
                  > types'.

                  Not getting what you mean. You cannot specify the set of representations - they can cary at will.

                  > Those representations will define types of link relations, which
                  > in turn define the application flow(s). Over time - other links/flows
                  > can be added, resources moved, media-types added etc. This is what I
                  > have understood as evolveability aspect of REST wrt the hypertext
                  > constraint.

                  Dig into this later.


                  >
                  >>
                  >> The funny thing for me was that, once actively accepting these consequences, it turns out there is really not so much that can change about a server given the above obligations.
                  >
                  > Ok - are you saying this is a Good Thing?

                  YES!! REST separates so nicely what can change from what can be kept stable in the face of evolving requirements. Its is magical - now that I see it :-)

                  Jan


                  >
                  > - Mike
                  >
                  >
                  > ------------------------------------
                  >
                  > Yahoo! Groups Links
                  >
                  >
                  >

                  -----------------------------------
                  Jan Algermissen, Consultant

                  Mail: algermissen@...
                  Blog: http://www.nordsc.com/blog/
                  Work: http://www.nordsc.com/
                  -----------------------------------
                • wahbedahbe
                  ... Really? Can you link to that? Was it the MUST a collection be returned as an Atom feed? thread? I didn t read any of Roy s comments that way... or maybe
                  Message 8 of 27 , Feb 1, 2010
                    --- In rest-discuss@yahoogroups.com, Jan Algermissen <algermissen1971@...> wrote:
                    > On Feb 1, 2010, at 2:54 PM, Mike Kelly wrote:
                    > > Jan Algermissen wrote:
                    > >> On Feb 1, 2010, at 1:38 PM, Mike Kelly wrote:
                    > >>> I think we need to agree on the definition of 'meaning' in this
                    > >>> context.. because, to me, it includes more than just the current set of
                    > >>> available link relations, and since we're not supposed to type resources
                    > >>> - the only approach I can see working is predefined application flows
                    > >>>
                    > >>
                    > >> Predefined application flows violate the hypermedia constraint and couple the server in a way that REST deliberately aims to avoid.
                    > >>
                    > >
                    > > Predefined application flows like AtomPub violate the hypermedia constraint?
                    >
                    > Yes. Roy confirmed that (recent post on atom-protocol list)


                    Really? Can you link to that? Was it the "MUST a collection be returned as an Atom feed?" thread?

                    I didn't read any of Roy's comments that way... or maybe I don't understand what you mean by "AtomPub's predefined flow".

                    Do you mean the Service -> Feed -> Entry hierarchy?

                    You said yourself in that thread that <collection> and <image> played conceptually similar roles. Isn't Page -> Image a similar two-level hierarchy? What is wrong with that?

                    I guess what I'm wondering is if AtomPub really defines an
                    "application flow" or do client writers mistake the hierarchy for one?

                    Regards,

                    Andrew
                  • Jan Algermissen
                    ... Yep. http://www.imc.org/atom-protocol/mail-archive/msg11487.html ... The requirement that a GET on a collection returns an Atom feed. That is unRESTful
                    Message 9 of 27 , Feb 1, 2010
                      On Feb 2, 2010, at 4:16 AM, wahbedahbe wrote:

                      >
                      > --- In rest-discuss@yahoogroups.com, Jan Algermissen <algermissen1971@...> wrote:
                      >> On Feb 1, 2010, at 2:54 PM, Mike Kelly wrote:
                      >>> Jan Algermissen wrote:
                      >>>> On Feb 1, 2010, at 1:38 PM, Mike Kelly wrote:
                      >>>>> I think we need to agree on the definition of 'meaning' in this
                      >>>>> context.. because, to me, it includes more than just the current set of
                      >>>>> available link relations, and since we're not supposed to type resources
                      >>>>> - the only approach I can see working is predefined application flows
                      >>>>>
                      >>>>
                      >>>> Predefined application flows violate the hypermedia constraint and couple the server in a way that REST deliberately aims to avoid.
                      >>>>
                      >>>
                      >>> Predefined application flows like AtomPub violate the hypermedia constraint?
                      >>
                      >> Yes. Roy confirmed that (recent post on atom-protocol list)
                      >
                      >
                      > Really? Can you link to that? Was it the "MUST a collection be returned as an Atom feed?" thread?

                      Yep. http://www.imc.org/atom-protocol/mail-archive/msg11487.html

                      >
                      > I didn't read any of Roy's comments that way... or maybe I don't understand what you mean by "AtomPub's predefined flow".

                      The requirement that a GET on a collection returns an Atom feed. That is unRESTful coupling because the client must not rely on such information but react to whatever it gets at runtime.

                      >
                      > Do you mean the Service -> Feed -> Entry hierarchy?

                      Yes, that's what it comes down to.

                      >
                      > You said yourself in that thread that <collection> and <image> played conceptually similar roles. Isn't Page -> Image a similar two-level hierarchy? What is wrong with that?

                      <collection href=""> points to 'a collection', that is ok. But predefining the media type that comes back from the collection is not. Might well be RSS or text/uri-list


                      >
                      > I guess what I'm wondering is if AtomPub really defines an
                      > "application flow" or do client writers mistake the hierarchy for one?

                      A truly RESTful client would do a GET on the collection and treat any response as 'correct' from a server POV (except for non-Collection representations, for
                      example an audio file).

                      Only if we do that the server's independent evolvability is preserved.

                      Jan

                      >
                      > Regards,
                      >
                      > Andrew
                      >
                      >
                      >
                      > ------------------------------------
                      >
                      > Yahoo! Groups Links
                      >
                      >
                      >

                      -----------------------------------
                      Jan Algermissen, Consultant

                      Mail: algermissen@...
                      Blog: http://www.nordsc.com/blog/
                      Work: http://www.nordsc.com/
                      -----------------------------------
                    • Mike Kelly
                      ... That post is about over-specification, not predefinition. And leads me to ask - What is an adequate specification , if not predefinition? - Mike
                      Message 10 of 27 , Feb 2, 2010
                        Jan Algermissen wrote:
                        > On Feb 2, 2010, at 4:16 AM, wahbedahbe wrote:
                        >
                        >
                        >> --- In rest-discuss@yahoogroups.com, Jan Algermissen <algermissen1971@...> wrote:
                        >>
                        >>> On Feb 1, 2010, at 2:54 PM, Mike Kelly wrote:
                        >>>
                        >>>> Jan Algermissen wrote:
                        >>>>
                        >>>>> On Feb 1, 2010, at 1:38 PM, Mike Kelly wrote:
                        >>>>>
                        >>>>>> I think we need to agree on the definition of 'meaning' in this
                        >>>>>> context.. because, to me, it includes more than just the current set of
                        >>>>>> available link relations, and since we're not supposed to type resources
                        >>>>>> - the only approach I can see working is predefined application flows
                        >>>>>>
                        >>>>>>
                        >>>>> Predefined application flows violate the hypermedia constraint and couple the server in a way that REST deliberately aims to avoid.
                        >>>>>
                        >>>>>
                        >>>> Predefined application flows like AtomPub violate the hypermedia constraint?
                        >>>>
                        >>> Yes. Roy confirmed that (recent post on atom-protocol list)
                        >>>
                        >> Really? Can you link to that? Was it the "MUST a collection be returned as an Atom feed?" thread?
                        >>
                        >
                        > Yep. http://www.imc.org/atom-protocol/mail-archive/msg11487.html
                        >

                        That post is about over-specification, not predefinition. And leads me
                        to ask - What is an 'adequate specification', if not predefinition?

                        - Mike
                      • Jan Algermissen
                        ... I understood Roy to be saying that it is an over-specifiction that AtomPub requires GETs on collections to return an Atom feed. Such a predefinition is an
                        Message 11 of 27 , Feb 2, 2010
                          On Feb 2, 2010, at 11:25 AM, Mike Kelly wrote:

                          > Jan Algermissen wrote:
                          >> On Feb 2, 2010, at 4:16 AM, wahbedahbe wrote:
                          >>
                          >>
                          >>> --- In rest-discuss@yahoogroups.com, Jan Algermissen <algermissen1971@...> wrote:
                          >>>
                          >>>> On Feb 1, 2010, at 2:54 PM, Mike Kelly wrote:
                          >>>>
                          >>>>> Jan Algermissen wrote:
                          >>>>>
                          >>>>>> On Feb 1, 2010, at 1:38 PM, Mike Kelly wrote:
                          >>>>>>
                          >>>>>>> I think we need to agree on the definition of 'meaning' in this
                          >>>>>>> context.. because, to me, it includes more than just the current set of
                          >>>>>>> available link relations, and since we're not supposed to type resources
                          >>>>>>> - the only approach I can see working is predefined application flows
                          >>>>>>>
                          >>>>>>>
                          >>>>>> Predefined application flows violate the hypermedia constraint and couple the server in a way that REST deliberately aims to avoid.
                          >>>>>>
                          >>>>>>
                          >>>>> Predefined application flows like AtomPub violate the hypermedia constraint?
                          >>>>>
                          >>>> Yes. Roy confirmed that (recent post on atom-protocol list)
                          >>>>
                          >>> Really? Can you link to that? Was it the "MUST a collection be returned as an Atom feed?" thread?
                          >>>
                          >>
                          >> Yep. http://www.imc.org/atom-protocol/mail-archive/msg11487.html
                          >>
                          >
                          > That post is about over-specification, not predefinition. And leads me
                          > to ask - What is an 'adequate specification', if not predefinition?

                          I understood Roy to be saying that it is an over-specifiction that AtomPub requires GETs on collections to return an Atom feed.

                          Such a predefinition is an over-specification in RESTland.

                          Jan

                          >
                          > - Mike
                          >
                          >
                          > ------------------------------------
                          >
                          > Yahoo! Groups Links
                          >
                          >
                          >

                          -----------------------------------
                          Jan Algermissen, Consultant
                          NORD Software Consulting

                          Mail: algermissen@...
                          Blog: http://www.nordsc.com/blog/
                          Work: http://www.nordsc.com/
                          -----------------------------------
                        • Mike Kelly
                          ... Maybe so, but the use of term over specification implies that there is infact an appropriate degree of specification i.e. a predefined flow with a more
                          Message 12 of 27 , Feb 2, 2010
                            Jan Algermissen wrote:
                            > On Feb 2, 2010, at 11:25 AM, Mike Kelly wrote:
                            >
                            >
                            >> Jan Algermissen wrote:
                            >>
                            >>> On Feb 2, 2010, at 4:16 AM, wahbedahbe wrote:
                            >>>
                            >>>
                            >>>
                            >>>> --- In rest-discuss@yahoogroups.com, Jan Algermissen <algermissen1971@...> wrote:
                            >>>>
                            >>>>
                            >>>>> On Feb 1, 2010, at 2:54 PM, Mike Kelly wrote:
                            >>>>>
                            >>>>>
                            >>>>>> Jan Algermissen wrote:
                            >>>>>>
                            >>>>>>
                            >>>>>>> On Feb 1, 2010, at 1:38 PM, Mike Kelly wrote:
                            >>>>>>>
                            >>>>>>>
                            >>>>>>>> I think we need to agree on the definition of 'meaning' in this
                            >>>>>>>> context.. because, to me, it includes more than just the current set of
                            >>>>>>>> available link relations, and since we're not supposed to type resources
                            >>>>>>>> - the only approach I can see working is predefined application flows
                            >>>>>>>>
                            >>>>>>>>
                            >>>>>>>>
                            >>>>>>> Predefined application flows violate the hypermedia constraint and couple the server in a way that REST deliberately aims to avoid.
                            >>>>>>>
                            >>>>>>>
                            >>>>>>>
                            >>>>>> Predefined application flows like AtomPub violate the hypermedia constraint?
                            >>>>>>
                            >>>>>>
                            >>>>> Yes. Roy confirmed that (recent post on atom-protocol list)
                            >>>>>
                            >>>>>
                            >>>> Really? Can you link to that? Was it the "MUST a collection be returned as an Atom feed?" thread?
                            >>>>
                            >>>>
                            >>> Yep. http://www.imc.org/atom-protocol/mail-archive/msg11487.html
                            >>>
                            >>>
                            >> That post is about over-specification, not predefinition. And leads me
                            >> to ask - What is an 'adequate specification', if not predefinition?
                            >>
                            >
                            > I understood Roy to be saying that it is an over-specifiction that AtomPub requires GETs on collections to return an Atom feed.
                            >
                            > Such a predefinition is an over-specification in RESTland.
                            >
                            > Jan
                            >

                            Maybe so, but the use of term "over" specification implies that there is
                            infact an appropriate degree of specification i.e. a predefined flow
                            with a more suitable level of liberalism.

                            - Mike
                          • wahbedahbe
                            ... Ok... agree on the above, but how do you define collection ? To me it s something that has a set of entries . So you get the hierarchy don t you? A
                            Message 13 of 27 , Feb 2, 2010
                              --- In rest-discuss@yahoogroups.com, Jan Algermissen <algermissen1971@...> wrote:
                              >
                              >
                              > On Feb 2, 2010, at 4:16 AM, wahbedahbe wrote:
                              >
                              > >
                              > > --- In rest-discuss@yahoogroups.com, Jan Algermissen <algermissen1971@> wrote:
                              > >> On Feb 1, 2010, at 2:54 PM, Mike Kelly wrote:
                              > >>> Jan Algermissen wrote:
                              > >>>> On Feb 1, 2010, at 1:38 PM, Mike Kelly wrote:
                              > >>>>> I think we need to agree on the definition of 'meaning' in this
                              > >>>>> context.. because, to me, it includes more than just the current set of
                              > >>>>> available link relations, and since we're not supposed to type resources
                              > >>>>> - the only approach I can see working is predefined application flows
                              > >>>>>
                              > >>>>
                              > >>>> Predefined application flows violate the hypermedia constraint and couple the server in a way that REST deliberately aims to avoid.
                              > >>>>
                              > >>>
                              > >>> Predefined application flows like AtomPub violate the hypermedia constraint?
                              > >>
                              > >> Yes. Roy confirmed that (recent post on atom-protocol list)
                              > >
                              > >
                              > > Really? Can you link to that? Was it the "MUST a collection be returned as an Atom feed?" thread?
                              >
                              > Yep. http://www.imc.org/atom-protocol/mail-archive/msg11487.html
                              >
                              > >
                              > > I didn't read any of Roy's comments that way... or maybe I don't understand what you mean by "AtomPub's predefined flow".
                              >
                              > The requirement that a GET on a collection returns an Atom feed. That is unRESTful coupling because the client must not rely on such information but react to whatever it gets at runtime.
                              >
                              > >
                              > > Do you mean the Service -> Feed -> Entry hierarchy?
                              >
                              > Yes, that's what it comes down to.
                              >
                              > >
                              > > You said yourself in that thread that <collection> and <image> played conceptually similar roles. Isn't Page -> Image a similar two-level hierarchy? What is wrong with that?
                              >
                              > <collection href=""> points to 'a collection', that is ok. But predefining the media type that comes back from the collection is not. Might well be RSS or text/uri-list
                              >
                              >
                              > >
                              > > I guess what I'm wondering is if AtomPub really defines an
                              > > "application flow" or do client writers mistake the hierarchy for one?
                              >
                              > A truly RESTful client would do a GET on the collection and treat any response as 'correct' from a server POV (except for non-Collection representations, for
                              > example an audio file).
                              >
                              > Only if we do that the server's independent evolvability is preserved.
                              >

                              Ok... agree on the above, but how do you define 'collection'? To me it's something that has a set of 'entries'. So you get the hierarchy don't you? A 'good' client can/should be flexible on the media types though (and the spec shouldn't try to restrict them). Perhaps the variability in media type means that the entries may be exclusively inline for some representations which just means that the hierarchy might not map to your addressable resources, but it's still there.


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