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

Understanding Steady States

Expand Messages
  • algermissen1971
    When a client is in a steady state, what makes up the meaning of the state (what information does the client use to determine the meaning)? a) The current
    Message 1 of 27 , Jan 24, 2010
      When a client is in a steady state, what makes up the meaning of the state (what information does the client use to determine the meaning)?

      a) The current representation (plus the understanding of the media types)
      b) The current representation (plus the understanding of the media types) and the request the client made (the knowledge of the semantics of the resource that the representation has been obtained from)
      c) b) and knowledge about all the requests it made before (this is wrong from a REST POV, but I include it for completeness)

      Note that b) includes knowledge about any conneg that might have happened. E.g. the client might have asked for

      GET /products/6676
      Accept: application/xhtml+xml;profile="http://foo.org/my-html-product-representation-uformats-profile

      and the server might have just answered with

      200 Ok
      Content-Type: application/xhtml+xml

      knowing that it serves the requested profile. (it did not say: your request for HTML with tht profile is 406 Not Acceptable). From the pure representation it is not detectable that the server sent this as a response to a request for 'a product representation'


      My understanding is b) but I am not entirely sure.


      Jan
    • Eric J. Bowman
      I ve never seen a ;profile attribute for a media type before, where does this come from? My apologies if I ve overlooked it... As to the issue of
      Message 2 of 27 , Jan 24, 2010
        I've never seen a ;profile attribute for a media type before, where
        does this come from? My apologies if I've overlooked it...

        As to the issue of steady-states, consider the browser. The user
        follows one link, but the next steady-state may only be achieved by
        dereferencing pertinent URIs within the initial representation. Your
        post implies that there's a 1:1 relationship between that initial
        representation's retrieval and the next steady-state.

        -Eric

        "algermissen1971" wrote:
        >
        > When a client is in a steady state, what makes up the meaning of the
        > state (what information does the client use to determine the meaning)?
        >
        > a) The current representation (plus the understanding of the media
        > types) b) The current representation (plus the understanding of the
        > media types) and the request the client made (the knowledge of the
        > semantics of the resource that the representation has been obtained
        > from) c) b) and knowledge about all the requests it made before (this
        > is wrong from a REST POV, but I include it for completeness)
        >
        > Note that b) includes knowledge about any conneg that might have
        > happened. E.g. the client might have asked for
        >
        > GET /products/6676
        > Accept: application/xhtml
        > +xml;profile="http://foo.org/my-html-product-representation-uformats-profile
        >
        > and the server might have just answered with
        >
        > 200 Ok
        > Content-Type: application/xhtml+xml
        >
        > knowing that it serves the requested profile. (it did not say: your
        > request for HTML with tht profile is 406 Not Acceptable). From the
        > pure representation it is not detectable that the server sent this as
        > a response to a request for 'a product representation'
        >
        >
        > My understanding is b) but I am not entirely sure.
        >
        >
        > Jan
        >
        >
        >
      • algermissen1971
        ... See references in It was just one aspect of my question, though. Consider this: is the
        Message 3 of 27 , Jan 24, 2010
          --- In rest-discuss@yahoogroups.com, "Eric J. Bowman" <eric@...> wrote:
          >
          > I've never seen a ;profile attribute for a media type before, where
          > does this come from? My apologies if I've overlooked it...

          See references in <http://tech.groups.yahoo.com/group/rest-discuss/message/14612>

          It was just one aspect of my question, though.

          Consider this: is the media type of a representation telling you enough to understand the current state or do you need the context of the request also? When you follow some <link rel="/featured-product" href="/products/3776"/> link and the servers sends an HTML page back do you understand the meaning of the steady state from looking at the Content-Type header or do you add-in the information that the server told you the resource you just requested is 'the featured product'?



          > As to the issue of steady-states, consider the browser. The user
          > follows one link, but the next steady-state may only be achieved by
          > dereferencing pertinent URIs within the initial representation. Your
          > post implies that there's a 1:1 relationship between that initial
          > representation's retrieval and the next steady-state.

          No. At least I did not want to imply that. The steady state is reached when all the outstanding sub-requests have been made and then, when the client has no pending requests - on what basis does it determine the meaning of the state?

          In a machine client this would mean: "what information is taken into account to determine the next transition to follow? Just the media types of the steady state or also the context of the request?

          Jan

          >
          > -Eric
          >
          > "algermissen1971" wrote:
          > >
          > > When a client is in a steady state, what makes up the meaning of the
          > > state (what information does the client use to determine the meaning)?
          > >
          > > a) The current representation (plus the understanding of the media
          > > types) b) The current representation (plus the understanding of the
          > > media types) and the request the client made (the knowledge of the
          > > semantics of the resource that the representation has been obtained
          > > from) c) b) and knowledge about all the requests it made before (this
          > > is wrong from a REST POV, but I include it for completeness)
          > >
          > > Note that b) includes knowledge about any conneg that might have
          > > happened. E.g. the client might have asked for
          > >
          > > GET /products/6676
          > > Accept: application/xhtml
          > > +xml;profile="http://foo.org/my-html-product-representation-uformats-profile
          > >
          > > and the server might have just answered with
          > >
          > > 200 Ok
          > > Content-Type: application/xhtml+xml
          > >
          > > knowing that it serves the requested profile. (it did not say: your
          > > request for HTML with tht profile is 406 Not Acceptable). From the
          > > pure representation it is not detectable that the server sent this as
          > > a response to a request for 'a product representation'
          > >
          > >
          > > My understanding is b) but I am not entirely sure.
          > >
          > >
          > > Jan
          > >
          > >
          > >
          >
        • algermissen1971
          ... Another way to ask this is: When you bookmark /products/3776 and later go back to it, do you know it represents a product? Or: If you send your friend the
          Message 4 of 27 , Jan 24, 2010
            --- In rest-discuss@yahoogroups.com, "algermissen1971" <algermissen1971@...> wrote:
            >
            >
            >
            > --- In rest-discuss@yahoogroups.com, "Eric J. Bowman" <eric@> wrote:
            > >
            > > I've never seen a ;profile attribute for a media type before, where
            > > does this come from? My apologies if I've overlooked it...
            >
            > See references in <http://tech.groups.yahoo.com/group/rest-discuss/message/14612>
            >
            > It was just one aspect of my question, though.
            >
            > Consider this: is the media type of a representation telling you enough to understand the current state or do you need the context of the request also? When you follow some <link rel="/featured-product" href="/products/3776"/> link and the servers sends an HTML page back do you understand the meaning of the steady state from looking at the Content-Type header or do you add-in the information that the server told you the resource you just requested is 'the featured product'?


            Another way to ask this is: When you bookmark /products/3776 and later go back to it, do you know it represents a product?

            Or: If you send your friend the link: /products/3776, do you say "Check this out" or "Check this cool product out"?

            And, when you receive "Check out /products/3776" do you know /products/3776 represents a product when you look at the representation?

            jan


            >
            >
            >
            > > As to the issue of steady-states, consider the browser. The user
            > > follows one link, but the next steady-state may only be achieved by
            > > dereferencing pertinent URIs within the initial representation. Your
            > > post implies that there's a 1:1 relationship between that initial
            > > representation's retrieval and the next steady-state.
            >
            > No. At least I did not want to imply that. The steady state is reached when all the outstanding sub-requests have been made and then, when the client has no pending requests - on what basis does it determine the meaning of the state?
            >
            > In a machine client this would mean: "what information is taken into account to determine the next transition to follow? Just the media types of the steady state or also the context of the request?
            >
            > Jan
            >
            > >
            > > -Eric
            > >
            > > "algermissen1971" wrote:
            > > >
            > > > When a client is in a steady state, what makes up the meaning of the
            > > > state (what information does the client use to determine the meaning)?
            > > >
            > > > a) The current representation (plus the understanding of the media
            > > > types) b) The current representation (plus the understanding of the
            > > > media types) and the request the client made (the knowledge of the
            > > > semantics of the resource that the representation has been obtained
            > > > from) c) b) and knowledge about all the requests it made before (this
            > > > is wrong from a REST POV, but I include it for completeness)
            > > >
            > > > Note that b) includes knowledge about any conneg that might have
            > > > happened. E.g. the client might have asked for
            > > >
            > > > GET /products/6676
            > > > Accept: application/xhtml
            > > > +xml;profile="http://foo.org/my-html-product-representation-uformats-profile
            > > >
            > > > and the server might have just answered with
            > > >
            > > > 200 Ok
            > > > Content-Type: application/xhtml+xml
            > > >
            > > > knowing that it serves the requested profile. (it did not say: your
            > > > request for HTML with tht profile is 406 Not Acceptable). From the
            > > > pure representation it is not detectable that the server sent this as
            > > > a response to a request for 'a product representation'
            > > >
            > > >
            > > > My understanding is b) but I am not entirely sure.
            > > >
            > > >
            > > > Jan
            > > >
            > > >
            > > >
            > >
            >
          • Mike Kelly
            ... Why is c necessarily wrong from a REST POV? I would say the meaning of the state is derived from the path taken through the flow of your hypertext-driven
            Message 5 of 27 , Jan 24, 2010
              algermissen1971 wrote:
              > When a client is in a steady state, what makes up the meaning of the state (what information does the client use to determine the meaning)?
              >
              > a) The current representation (plus the understanding of the media types)
              > b) The current representation (plus the understanding of the media types) and the request the client made (the knowledge of the semantics of the resource that the representation has been obtained from)
              > c) b) and knowledge about all the requests it made before (this is wrong from a REST POV, but I include it for completeness)
              >

              Why is c necessarily wrong from a REST POV?

              I would say the 'meaning' of the state is derived from the path taken
              through the flow of your hypertext-driven application, so it would
              include all state transitions taken from a given 'entry point' in your
              application.

              - Mike
            • algermissen1971
              ... Because the meaning of a given state in a RESTful application does not depend on whatever happened before. For example, consider an IO library where you
              Message 6 of 27 , Jan 24, 2010
                --- In rest-discuss@yahoogroups.com, Mike Kelly <mike@...> wrote:
                >
                > algermissen1971 wrote:
                > > When a client is in a steady state, what makes up the meaning of the state (what information does the client use to determine the meaning)?
                > >
                > > a) The current representation (plus the understanding of the media types)
                > > b) The current representation (plus the understanding of the media types) and the request the client made (the knowledge of the semantics of the resource that the representation has been obtained from)
                > > c) b) and knowledge about all the requests it made before (this is wrong from a REST POV, but I include it for completeness)
                > >
                >
                > Why is c necessarily wrong from a REST POV?

                Because the meaning of a given state in a RESTful application does not depend on whatever happened before.

                For example, consider an IO library where you need to remember that you opened a file. You read the next chunk, knowing it is still open, not because the state of the file descriptor provides a transition that lets you read a chunk. With REST you do not have a priori knowledge about the state the service (the file descriptor) goes through. You can understand each state in isolation.

                Jan


                >
                > I would say the 'meaning' of the state is derived from the path taken
                > through the flow of your hypertext-driven application, so it would
                > include all state transitions taken from a given 'entry point' in your
                > application.
                >
                > - Mike
                >
              • Mike Kelly
                ... The client/application state.. ? I m not so sure given that hypertext is the engine of application state - the only way for the client to understand the
                Message 7 of 27 , Jan 24, 2010
                  algermissen1971 wrote:
                  > --- In rest-discuss@yahoogroups.com, Mike Kelly <mike@...> wrote:
                  >
                  >> algermissen1971 wrote:
                  >>
                  >>> When a client is in a steady state, what makes up the meaning of the state (what information does the client use to determine the meaning)?
                  >>>
                  >>> a) The current representation (plus the understanding of the media types)
                  >>> b) The current representation (plus the understanding of the media types) and the request the client made (the knowledge of the semantics of the resource that the representation has been obtained from)
                  >>> c) b) and knowledge about all the requests it made before (this is wrong from a REST POV, but I include it for completeness)
                  >>>
                  >>>
                  >> Why is c necessarily wrong from a REST POV?
                  >>
                  >
                  > Because the meaning of a given state in a RESTful application does not depend on whatever happened before.
                  >

                  The client/application state.. ?

                  I'm not so sure given that 'hypertext is the engine of application
                  state' - 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.

                  - Mike
                • Eric J. Bowman
                  (response to off-list message about off-list messages and rest-discuss) I had the same problem here, I forgot how I solved it, but now I can t use the Web
                  Message 8 of 27 , Jan 24, 2010
                    (response to off-list message about off-list messages and rest-discuss)
                    I had the same problem here, I forgot how I solved it, but now I can't
                    use the Web interface -- only e-mail -- to post to rest-discuss. I
                    wish I could remember, seeing as how you're stuck with the opposite.

                    I'm going to hold off on answering your question until I have the demo
                    I've been working on furiously for the past two weeks, posted. It
                    addresses a variety of issues regarding REST, Xforms, and client-side
                    XSLT. Due to the demo's nature as client-side XSLT, I'm wearing my
                    application logic on my sleeve as hypertext (which goes beyond the
                    hypertext constraint, as opposed to breaking said constraint).

                    The application logic, whether the XSLT transformation is run on the
                    client or the server, is entirely based on link relations. In fact,
                    the easiest part of distilling out a static example from my dynamic
                    project, turned out to be dismantling content negotiation. All I did
                    was edit my Atom source files' link relation @hrefs by adding filename
                    extensions. Which frees the demo up to run a directory browser so you
                    can introspect my files, including the content of dot files.

                    Since the application logic is based on link relations, changing the
                    URLs in the source Atom files also changed the URLs in the XHTML output
                    without my having to change the XSLT stylesheet. I think my demo will
                    answer a lot of the questions you've been asking lately about machine
                    clients, or at least give you plenty of food for thought.

                    Bear with for a few days, I almost posted it already but I've torn the
                    httpd apart again... the httpd running the demo is a FOSS project I've
                    adopted and adapted to be a prototyping framework for REST development.
                    The source code for the httpd is posted as part of the demo. Mostly not
                    my httpd code, but everything else is, save a line of XSLT and an XPATH
                    statement my partner contributed when I got stuck.

                    While it looks like the same demo I've been posting occasionally for 3
                    1/2 years, there came a point where I took off my architect hat and
                    decided to write the damn code myself, after failing to explain to many
                    different coders how to base application logic on link relations. I'll
                    put my markup and CSS up against anyone's, and with more practice I'll
                    be saying that about my XSLT as well. This should lay to rest the
                    recurring concerns about my skillz every time I try to contribute
                    something of my knowledge (Web developer since Dec. 1993) somewhere.

                    Like yesterday on www-tag when I was more-or-less accused of inventing
                    the Content-Script-Type header, in response to my polite suggestion that
                    it be considered within the context of an ongoing discussion. Sigh.
                    Of course, my demo implements said header, and shows just exactly how
                    it can be used to solve the issue of distinguishing between scripted
                    and unscripted (X)HTML, and the issue of privilege escalation that I'm
                    patiently trying to explain to w3c folks where media type identifiers
                    other than text/plain are concerned.

                    Jan, I really should point out that you're saying "media type" where
                    you really mean "media type identifier", but the two are not the same
                    thing. I've only recently decided that pointing this out isn't nit-
                    picking, but crucial to understanding Web architecture (which REST is a
                    subset of). Anyway, I'll save my elaboration on why media type
                    identifers only describe containers, for some other time. You're
                    leaning in a direction I reject out of hand, which is that a media type
                    identifier is a contract. Contracts reside within the containers.

                    -Eric
                  • Eric J. Bowman
                    (response to off-list message about off-list messages and rest-discuss) I had the same problem here, I forgot how I solved it, but now I can t use the Web
                    Message 9 of 27 , Jan 24, 2010
                      (response to off-list message about off-list messages and rest-discuss)
                      I had the same problem here, I forgot how I solved it, but now I can't
                      use the Web interface -- only e-mail -- to post to rest-discuss. I
                      wish I could remember, seeing as how you're stuck with the opposite.

                      I'm going to hold off on answering your question until I have the demo
                      I've been working on furiously for the past two weeks, posted. It
                      addresses a variety of issues regarding REST, Xforms, and client-side
                      XSLT. Due to the demo's nature as client-side XSLT, I'm wearing my
                      application logic on my sleeve as hypertext (which goes beyond the
                      hypertext constraint, as opposed to breaking said constraint).

                      The application logic, whether the XSLT transformation is run on the
                      client or the server, is entirely based on link relations. In fact,
                      the easiest part of distilling out a static example from my dynamic
                      project, turned out to be dismantling content negotiation. All I did
                      was edit my Atom source files' link relation @hrefs by adding filename
                      extensions. Which frees the demo up to run a directory browser so you
                      can introspect my files, including the content of dot files.

                      Since the application logic is based on link relations, changing the
                      URLs in the source Atom files also changed the URLs in the XHTML output
                      without my having to change the XSLT stylesheet. I think my demo will
                      answer a lot of the questions you've been asking lately about machine
                      clients, or at least give you plenty of food for thought.

                      Bear with for a few days, I almost posted it already but I've torn the
                      httpd apart again... the httpd running the demo is a FOSS project I've
                      adopted and adapted to be a prototyping framework for REST development.
                      The source code for the httpd is posted as part of the demo. Mostly not
                      my httpd code, but everything else is, save a line of XSLT and an XPATH
                      statement my partner contributed when I got stuck.

                      While it looks like the same demo I've been posting occasionally for 3
                      1/2 years, there came a point where I took off my architect hat and
                      decided to write the damn code myself, after failing to explain to many
                      different coders how to base application logic on link relations. I'll
                      put my markup and CSS up against anyone's, and with more practice I'll
                      be saying that about my XSLT as well. This should lay to rest the
                      recurring concerns about my skillz every time I try to contribute
                      something of my knowledge (Web developer since Dec. 1993) somewhere.

                      Like yesterday on www-tag when I was more-or-less accused of inventing
                      the Content-Script-Type header, in response to my polite suggestion that
                      it be considered within the context of an ongoing discussion. Sigh.
                      Of course, my demo implements said header, and shows just exactly how
                      it can be used to solve the issue of distinguishing between scripted
                      and unscripted (X)HTML, and the issue of privilege escalation that I'm
                      patiently trying to explain to w3c folks where media type identifiers
                      other than text/plain are concerned.

                      Jan, I really should point out that you're saying "media type" where
                      you really mean "media type identifier", but the two are not the same
                      thing. I've only recently decided that pointing this out isn't nit-
                      picking, but crucial to understanding Web architecture (which REST is a
                      subset of). Anyway, I'll save my elaboration on why media type
                      identifers only describe containers, for some other time. You're
                      leaning in a direction I reject out of hand, which is that a media type
                      identifier is a contract. Contracts reside within the containers.

                      -Eric
                    • Eric J. Bowman
                      Sorry for the double-post, list. I think y all know how it goes with rest-discuss posting some days, right? ;-) -Eric
                      Message 10 of 27 , Jan 24, 2010
                        Sorry for the double-post, list. I think y'all know how it goes with
                        rest-discuss posting some days, right? ;-)

                        -Eric
                      • Jan Algermissen
                        ... 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
                        Message 11 of 27 , Jan 24, 2010
                          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.

                          (Which makes a nice principle for media type design)

                          Jan




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

                          Mail: algermissen@...
                          Blog: http://www.nordsc.com/blog/
                          Work: http://www.nordsc.com/
                          -----------------------------------
                        • Mike Kelly
                          ... Are we drawing a distinction here between steady-state and entry-point? From my understanding - you are describing the latter, but not necessarily the
                          Message 12 of 27 , Jan 24, 2010
                            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?
                            From my understanding - you are describing the latter, but not
                            necessarily the former.

                            I'm thinking purely from a client perspective. A server shouldn't be
                            aware of any such 'context' since there is no shared state.

                            - Mike
                          • Jan Algermissen
                            ... Hmm, IMHO each steady state is a potential entry point. Jan ... Jan Algermissen, Consultant Mail: algermissen@acm.org Blog: http://www.nordsc.com/blog/
                            Message 13 of 27 , Jan 24, 2010
                              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.

                              Jan


                              > From my understanding - you are describing the latter, but not
                              > necessarily the former.
                              >
                              > I'm thinking purely from a client perspective. A server shouldn't be
                              > aware of any such 'context' since there is no shared state.
                              >
                              > - Mike

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

                              Mail: algermissen@...
                              Blog: http://www.nordsc.com/blog/
                              Work: http://www.nordsc.com/
                              -----------------------------------
                            • Jan Algermissen
                              ... I knew it wasn t my clever observation but that Roy wrote it somewhere... here is the link:
                              Message 14 of 27 , Jan 24, 2010
                                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>

                                Jan




                                >
                                > Jan
                                >
                                >
                                >> From my understanding - you are describing the latter, but not
                                >> necessarily the former.
                                >>
                                >> I'm thinking purely from a client perspective. A server shouldn't be
                                >> aware of any such 'context' since there is no shared state.
                                >>
                                >> - Mike
                                >
                                > -----------------------------------
                                > Jan Algermissen, Consultant
                                >
                                > Mail: algermissen@...
                                > Blog: http://www.nordsc.com/blog/
                                > Work: http://www.nordsc.com/
                                > -----------------------------------
                                >
                                >
                                >
                                >
                                >
                                > ------------------------------------
                                >
                                > Yahoo! Groups Links
                                >
                                >
                                >

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

                                Mail: algermissen@...
                                Blog: http://www.nordsc.com/blog/
                                Work: http://www.nordsc.com/
                                -----------------------------------
                              • 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 15 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 16 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 17 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 18 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 19 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 20 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 21 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 22 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 23 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 24 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 25 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 26 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 27 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.