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

Definition of a Hypermedia Client

Expand Messages
  • mike amundsen
    ** cross-posted ** I m contemplating a working definition for a Hypermedia Client. Here are my first attempts: 1 - A Hypermedia Client supports advancing
    Message 1 of 22 , Jun 10, 2011
    View Source
    • 0 Attachment
      ** cross-posted **

      I'm contemplating a working definition for a "Hypermedia Client." Here are my first attempts:

      1 - "A Hypermedia Client supports advancing it's own application state based on application control information supplied in server responses."

      2 - "A Hypermedia Client supports advancing application state by sending requests to servers based on application control information supplied in server responses."

      3 - "A Hypermedia Client supports advancing application state by sending requests to servers based on application control information embedded within, or as a layer above, the presentation of information supplied in server responses."

      The germ of this definition is loosely based on a Fielding's description of "Distributed Hypermedia"[1]

      The point of this exercise is:
      1) Is there a generally agreed definition?
      2) Can a definition be useful in evaluating/analyzing existing implementations? (e.g. "Is 'this' a hypermedia client?")
      3) Can a definition be useful in creating new implementations that "meet" the definition? (e.g. "Here is what you need to build a hypermedia client....")

      Any/all feedback is welcome.  Possibly there is "prior art" here of which I am unaware; please point me to any reference material you may think useful. Maybe you've gone through a similar process and would like to send along your experiences.

      Thanks in advance.

    • Eric J. Bowman
      ... OK, I ll bite. I doubt we disagree, but I think your wording leads the wrong direction; taken out of the context of the thesis, the presence of
      Message 2 of 22 , Jun 13, 2011
      View Source
      • 0 Attachment
        mike amundsen wrote:
        >
        > I'm contemplating a working definition for a "Hypermedia Client."
        > Here are my first attempts:
        >

        OK, I'll bite. I doubt we disagree, but I think your wording leads the
        wrong direction; taken out of the context of the thesis, "the presence
        of application control information" may be easily misconstrued to also
        apply to javascript, when Roy meant it as linking/posting.

        >
        > 1 - "A Hypermedia Client supports advancing it's own application
        > state based on application control information supplied in server
        > responses."
        >

        Implies that the server controls the application state, first by using
        "client" instead of "user-agent". It's the user who chooses which
        application state to transition to; one option is a return to the
        previous state (back button), which isn't supplied in server responses.

        >
        > 2 - "A Hypermedia Client supports advancing application state by
        > sending requests to servers based on application control information
        > supplied in server responses."
        >

        User-agents are supposed to follow their noses, this sounds like servers
        leading user-agents about by the nose. What I mean is, the server can
        only supply state-transition *options* (control information), not state-
        transition *control* (control directives). It violates REST to use HTML
        meta-redirection.

        >
        > 3 - "A Hypermedia Client supports advancing application state by
        > sending requests to servers based on application control information
        > embedded within, or as a layer above, the presentation of information
        > supplied in server responses."
        >

        Still doesn't account for that pesky back button; nor does it account
        for state transitions derived from user input, IP address or REFERER
        header. Your wording makes it sound like the user-agent has knowledge
        of what application state will result from following a given transition.

        -Eric
      • Glenn Block
        Great to see you fleshing this out. In terms of prior art, Darrel has done a bunch of work around hypermedia clients with his Rest Agent stuff. A few other
        Message 3 of 22 , Oct 22, 2011
        View Source
        • 0 Attachment
          Great to see you fleshing this out. In terms of prior art, Darrel has done a bunch of work around hypermedia clients with his Rest Agent stuff.
           
          A few other thoughts
           
          1. A hypermedia client is not coupled to the uri space of the application / does not contain hard coded logic for uris on the server.
           
          2. A hypermedia client ignores hypermedia controls that it cannot handle / it does not break by the presence of new hypermedia controls.
           
          3. A hypermedia client advances application state by choosing from available hypermedia controls in server responses.


           
          On Fri, Jun 10, 2011 at 1:44 PM, mike amundsen <mamund@...> wrote:
           

          ** cross-posted **

          I'm contemplating a working definition for a "Hypermedia Client." Here are my first attempts:

          1 - "A Hypermedia Client supports advancing it's own application state based on application control information supplied in server responses."

          2 - "A Hypermedia Client supports advancing application state by sending requests to servers based on application control information supplied in server responses."

          3 - "A Hypermedia Client supports advancing application state by sending requests to servers based on application control information embedded within, or as a layer above, the presentation of information supplied in server responses."

          The germ of this definition is loosely based on a Fielding's description of "Distributed Hypermedia"[1]

          The point of this exercise is:
          1) Is there a generally agreed definition?
          2) Can a definition be useful in evaluating/analyzing existing implementations? (e.g. "Is 'this' a hypermedia client?")
          3) Can a definition be useful in creating new implementations that "meet" the definition? (e.g. "Here is what you need to build a hypermedia client....")

          Any/all feedback is welcome.  Possibly there is "prior art" here of which I am unaware; please point me to any reference material you may think useful. Maybe you've gone through a similar process and would like to send along your experiences.

          Thanks in advance.


        • Glenn Block
          I owuld add one exception to 1, which is the application root as there needs to be some known uri which is the entry point of the application otherwise you ll
          Message 4 of 22 , Oct 22, 2011
          View Source
          • 0 Attachment
            I owuld add one exception to 1, which is the application root as there needs to be some known uri which is the entry point of the application otherwise you'll never access the application in the first place....

            On Sat, Oct 22, 2011 at 8:08 PM, Glenn Block <glenn.block@...> wrote:
            Great to see you fleshing this out. In terms of prior art, Darrel has done a bunch of work around hypermedia clients with his Rest Agent stuff.
             
            A few other thoughts
             
            1. A hypermedia client is not coupled to the uri space of the application / does not contain hard coded logic for uris on the server.
             
            2. A hypermedia client ignores hypermedia controls that it cannot handle / it does not break by the presence of new hypermedia controls.
             
            3. A hypermedia client advances application state by choosing from available hypermedia controls in server responses.


             
            On Fri, Jun 10, 2011 at 1:44 PM, mike amundsen <mamund@...> wrote:
             

            ** cross-posted **

            I'm contemplating a working definition for a "Hypermedia Client." Here are my first attempts:

            1 - "A Hypermedia Client supports advancing it's own application state based on application control information supplied in server responses."

            2 - "A Hypermedia Client supports advancing application state by sending requests to servers based on application control information supplied in server responses."

            3 - "A Hypermedia Client supports advancing application state by sending requests to servers based on application control information embedded within, or as a layer above, the presentation of information supplied in server responses."

            The germ of this definition is loosely based on a Fielding's description of "Distributed Hypermedia"[1]

            The point of this exercise is:
            1) Is there a generally agreed definition?
            2) Can a definition be useful in evaluating/analyzing existing implementations? (e.g. "Is 'this' a hypermedia client?")
            3) Can a definition be useful in creating new implementations that "meet" the definition? (e.g. "Here is what you need to build a hypermedia client....")

            Any/all feedback is welcome.  Possibly there is "prior art" here of which I am unaware; please point me to any reference material you may think useful. Maybe you've gone through a similar process and would like to send along your experiences.

            Thanks in advance.



          • Jan Algermissen
            ... No necessarily because the client could obtain that URI from a entry-point-by-service-type lookup (e.g. via DNS[1]) Nevertheless, I d make clear (sort of
            Message 5 of 22 , Oct 23, 2011
            View Source
            • 0 Attachment
              On Oct 23, 2011, at 5:12 AM, Glenn Block wrote:

              > I owuld add one exception to 1, which is the application root as there needs to be some known uri which is the entry point of the application otherwise you'll never access the application in the first place....

              No necessarily because the client could obtain that URI from a entry-point-by-service-type lookup (e.g. via DNS[1])

              Nevertheless, I'd make clear (sort of as Glenn suggests) that clients typically know entry URIs (maybe even many) of applications. Furthermore, I'd make explicit that it is perfectly fine for clients to keep those entry URIs for as long as they wish[2] (aka bookmarking) and that this puts a responsibility on servers to maintain all entry URIs over time ("Cool URIs don't change..." [3]).

              Jan


              [1] http://www.infoq.com/articles/rest-discovery-dns
              [2] Until they see a 40 Gone for it
              [3] http://www.w3.org/Provider/Style/URI.html


              >
              > On Sat, Oct 22, 2011 at 8:08 PM, Glenn Block <glenn.block@...> wrote:
              > Great to see you fleshing this out. In terms of prior art, Darrel has done a bunch of work around hypermedia clients with his Rest Agent stuff.
              >
              > A few other thoughts
              >
              > 1. A hypermedia client is not coupled to the uri space of the application / does not contain hard coded logic for uris on the server.
              >
              > 2. A hypermedia client ignores hypermedia controls that it cannot handle / it does not break by the presence of new hypermedia controls.
              >
              > 3. A hypermedia client advances application state by choosing from available hypermedia controls in server responses.
              >
              >
              >
              > On Fri, Jun 10, 2011 at 1:44 PM, mike amundsen <mamund@...> wrote:
              >
              >
              > ** cross-posted **
              >
              > I'm contemplating a working definition for a "Hypermedia Client." Here are my first attempts:
              >
              > 1 - "A Hypermedia Client supports advancing it's own application state based on application control information supplied in server responses."
              >
              > 2 - "A Hypermedia Client supports advancing application state by sending requests to servers based on application control information supplied in server responses."
              >
              > 3 - "A Hypermedia Client supports advancing application state by sending requests to servers based on application control information embedded within, or as a layer above, the presentation of information supplied in server responses."
              >
              > The germ of this definition is loosely based on a Fielding's description of "Distributed Hypermedia"[1]
              >
              > The point of this exercise is:
              > 1) Is there a generally agreed definition?
              > 2) Can a definition be useful in evaluating/analyzing existing implementations? (e.g. "Is 'this' a hypermedia client?")
              > 3) Can a definition be useful in creating new implementations that "meet" the definition? (e.g. "Here is what you need to build a hypermedia client....")
              >
              > Any/all feedback is welcome. Possibly there is "prior art" here of which I am unaware; please point me to any reference material you may think useful. Maybe you've gone through a similar process and would like to send along your experiences.
              >
              > Thanks in advance.
              >
              > [1] http://www.ics.uci.edu/~fielding/pubs/dissertation/web_arch_domain.htm#sec_4_1_3
              >
              > mca
              > http://amundsen.com/blog/
              > http://twitter.com@mamund
              > http://mamund.com/foaf.rdf#me
              >
              > #RESTFest 2011 - Aug 18-20
              > http://restfest.org
              >
              >
              >
              >
              >
              >
              >
            • mike amundsen
              Glenn: are you indicating that you would prefer to use definition #1 as your defintion of a hypermedia client (along w/ something regarding starting URIs)?
              Message 6 of 22 , Oct 23, 2011
              View Source
              • 0 Attachment
                Glenn:

                are you indicating that you would prefer to use definition #1 as your "defintion of a hypermedia client" (along w/ something regarding starting URIs)?

                mca
                http://amundsen.com/blog/
                http://twitter.com@mamund
                http://mamund.com/foaf.rdf#me




                On Sat, Oct 22, 2011 at 23:12, Glenn Block <glenn.block@...> wrote:
                I owuld add one exception to 1, which is the application root as there needs to be some known uri which is the entry point of the application otherwise you'll never access the application in the first place....


                On Sat, Oct 22, 2011 at 8:08 PM, Glenn Block <glenn.block@...> wrote:
                Great to see you fleshing this out. In terms of prior art, Darrel has done a bunch of work around hypermedia clients with his Rest Agent stuff.
                 
                A few other thoughts
                 
                1. A hypermedia client is not coupled to the uri space of the application / does not contain hard coded logic for uris on the server.
                 
                2. A hypermedia client ignores hypermedia controls that it cannot handle / it does not break by the presence of new hypermedia controls.
                 
                3. A hypermedia client advances application state by choosing from available hypermedia controls in server responses.


                 
                On Fri, Jun 10, 2011 at 1:44 PM, mike amundsen <mamund@...> wrote:
                 

                ** cross-posted **

                I'm contemplating a working definition for a "Hypermedia Client." Here are my first attempts:

                1 - "A Hypermedia Client supports advancing it's own application state based on application control information supplied in server responses."

                2 - "A Hypermedia Client supports advancing application state by sending requests to servers based on application control information supplied in server responses."

                3 - "A Hypermedia Client supports advancing application state by sending requests to servers based on application control information embedded within, or as a layer above, the presentation of information supplied in server responses."

                The germ of this definition is loosely based on a Fielding's description of "Distributed Hypermedia"[1]

                The point of this exercise is:
                1) Is there a generally agreed definition?
                2) Can a definition be useful in evaluating/analyzing existing implementations? (e.g. "Is 'this' a hypermedia client?")
                3) Can a definition be useful in creating new implementations that "meet" the definition? (e.g. "Here is what you need to build a hypermedia client....")

                Any/all feedback is welcome.  Possibly there is "prior art" here of which I am unaware; please point me to any reference material you may think useful. Maybe you've gone through a similar process and would like to send along your experiences.

                Thanks in advance.




              • bruce.krakower
                Regarding evolvability, can we really say if new hypermedia controls should or shouldn t break a hypermedia client? This seems to get a bit fuzzy when a new
                Message 7 of 22 , Oct 23, 2011
                View Source
                • 0 Attachment
                  Regarding evolvability, can we really say if new hypermedia controls should or shouldn't "break" a hypermedia client? This seems to get a bit fuzzy when a new resource interaction may be required for a given application domain.
                • Glenn Block
                  You mean in your definitions. #1 is my lean with a clarification that the server is offering up available transitions and the client selects the appropriate
                  Message 8 of 22 , Oct 23, 2011
                  View Source
                  • 0 Attachment
                    You mean in your definitions. #1 is my lean with a clarification that the server is offering up available transitions and the client selects the appropriate one based on application specific logic.

                    meaning a hypermedia client is not dumb, but it's range of choices is provided by the server.

                    the current definition implies the client is force fed by the server.

                    Sent from my Windows Phone

                    From: mike amundsen
                    Sent: 10/23/2011 7:02 AM
                    To: Glenn Block
                    Cc: rest-discuss; hypermedia-web@...
                    Subject: Re: [rest-discuss] Definition of a Hypermedia Client

                    Glenn:

                    are you indicating that you would prefer to use definition #1 as your "defintion of a hypermedia client" (along w/ something regarding starting URIs)?

                    mca
                    http://amundsen.com/blog/
                    http://twitter.com@mamund
                    http://mamund.com/foaf.rdf#me




                    On Sat, Oct 22, 2011 at 23:12, Glenn Block <glenn.block@...> wrote:
                    I owuld add one exception to 1, which is the application root as there needs to be some known uri which is the entry point of the application otherwise you'll never access the application in the first place....


                    On Sat, Oct 22, 2011 at 8:08 PM, Glenn Block <glenn.block@...> wrote:
                    Great to see you fleshing this out. In terms of prior art, Darrel has done a bunch of work around hypermedia clients with his Rest Agent stuff.
                     
                    A few other thoughts
                     
                    1. A hypermedia client is not coupled to the uri space of the application / does not contain hard coded logic for uris on the server.
                     
                    2. A hypermedia client ignores hypermedia controls that it cannot handle / it does not break by the presence of new hypermedia controls.
                     
                    3. A hypermedia client advances application state by choosing from available hypermedia controls in server responses.


                     
                    On Fri, Jun 10, 2011 at 1:44 PM, mike amundsen <mamund@...> wrote:
                     

                    ** cross-posted **

                    I'm contemplating a working definition for a "Hypermedia Client." Here are my first attempts:

                    1 - "A Hypermedia Client supports advancing it's own application state based on application control information supplied in server responses."

                    2 - "A Hypermedia Client supports advancing application state by sending requests to servers based on application control information supplied in server responses."

                    3 - "A Hypermedia Client supports advancing application state by sending requests to servers based on application control information embedded within, or as a layer above, the presentation of information supplied in server responses."

                    The germ of this definition is loosely based on a Fielding's description of "Distributed Hypermedia"[1]

                    The point of this exercise is:
                    1) Is there a generally agreed definition?
                    2) Can a definition be useful in evaluating/analyzing existing implementations? (e.g. "Is 'this' a hypermedia client?")
                    3) Can a definition be useful in creating new implementations that "meet" the definition? (e.g. "Here is what you need to build a hypermedia client....")

                    Any/all feedback is welcome.  Possibly there is "prior art" here of which I am unaware; please point me to any reference material you may think useful. Maybe you've gone through a similar process and would like to send along your experiences.

                    Thanks in advance.




                  • Glenn Block
                    I see. Then I would say the notion of one or more application roots that the client is aware of is not an anti pattern. Sent from my Windows Phone From: Jan
                    Message 9 of 22 , Oct 23, 2011
                    View Source
                    • 0 Attachment
                      I see. Then I would say the notion of one or more application roots
                      that the client is aware of is not an anti pattern.

                      Sent from my Windows Phone
                      From: Jan Algermissen
                      Sent: 10/23/2011 1:50 AM
                      To: Glenn Block
                      Cc: mike amundsen; rest-discuss; hypermedia-web@...
                      Subject: Re: [rest-discuss] Definition of a Hypermedia Client

                      On Oct 23, 2011, at 5:12 AM, Glenn Block wrote:

                      > I owuld add one exception to 1, which is the application root as there needs to be some known uri which is the entry point of the application otherwise you'll never access the application in the first place....

                      No necessarily because the client could obtain that URI from a
                      entry-point-by-service-type lookup (e.g. via DNS[1])

                      Nevertheless, I'd make clear (sort of as Glenn suggests) that clients
                      typically know entry URIs (maybe even many) of applications.
                      Furthermore, I'd make explicit that it is perfectly fine for clients
                      to keep those entry URIs for as long as they wish[2] (aka bookmarking)
                      and that this puts a responsibility on servers to maintain all entry
                      URIs over time ("Cool URIs don't change..." [3]).

                      Jan


                      [1] http://www.infoq.com/articles/rest-discovery-dns
                      [2] Until they see a 40 Gone for it
                      [3] http://www.w3.org/Provider/Style/URI.html


                      >
                      > On Sat, Oct 22, 2011 at 8:08 PM, Glenn Block <glenn.block@...> wrote:
                      > Great to see you fleshing this out. In terms of prior art, Darrel has done a bunch of work around hypermedia clients with his Rest Agent stuff.
                      >
                      > A few other thoughts
                      >
                      > 1. A hypermedia client is not coupled to the uri space of the application / does not contain hard coded logic for uris on the server.
                      >
                      > 2. A hypermedia client ignores hypermedia controls that it cannot handle / it does not break by the presence of new hypermedia controls.
                      >
                      > 3. A hypermedia client advances application state by choosing from available hypermedia controls in server responses.
                      >
                      >
                      >
                      > On Fri, Jun 10, 2011 at 1:44 PM, mike amundsen <mamund@...> wrote:
                      >
                      >
                      > ** cross-posted **
                      >
                      > I'm contemplating a working definition for a "Hypermedia Client." Here are my first attempts:
                      >
                      > 1 - "A Hypermedia Client supports advancing it's own application state based on application control information supplied in server responses."
                      >
                      > 2 - "A Hypermedia Client supports advancing application state by sending requests to servers based on application control information supplied in server responses."
                      >
                      > 3 - "A Hypermedia Client supports advancing application state by sending requests to servers based on application control information embedded within, or as a layer above, the presentation of information supplied in server responses."
                      >
                      > The germ of this definition is loosely based on a Fielding's description of "Distributed Hypermedia"[1]
                      >
                      > The point of this exercise is:
                      > 1) Is there a generally agreed definition?
                      > 2) Can a definition be useful in evaluating/analyzing existing implementations? (e.g. "Is 'this' a hypermedia client?")
                      > 3) Can a definition be useful in creating new implementations that "meet" the definition? (e.g. "Here is what you need to build a hypermedia client....")
                      >
                      > Any/all feedback is welcome. Possibly there is "prior art" here of which I am unaware; please point me to any reference material you may think useful. Maybe you've gone through a similar process and would like to send along your experiences.
                      >
                      > Thanks in advance.
                      >
                      > [1] http://www.ics.uci.edu/~fielding/pubs/dissertation/web_arch_domain.htm#sec_4_1_3
                      >
                      > mca
                      > http://amundsen.com/blog/
                      > http://twitter.com@mamund
                      > http://mamund.com/foaf.rdf#me
                      >
                      > #RESTFest 2011 - Aug 18-20
                      > http://restfest.org
                      >
                      >
                      >
                      >
                      >
                      >
                      >
                    • mike amundsen
                      thanks for the comments. mca http://amundsen.com/blog/ http://twitter.com@mamund http://mamund.com/foaf.rdf#me
                      Message 10 of 22 , Oct 23, 2011
                      View Source
                      • 0 Attachment
                        thanks for the comments.

                        mca
                        http://amundsen.com/blog/
                        http://twitter.com@mamund
                        http://mamund.com/foaf.rdf#me




                        On Sun, Oct 23, 2011 at 13:59, Glenn Block <glenn.block@...> wrote:
                        You mean in your definitions. #1 is my lean with a clarification that the server is offering up available transitions and the client selects the appropriate one based on application specific logic.

                        meaning a hypermedia client is not dumb, but it's range of choices is provided by the server.

                        the current definition implies the client is force fed by the server.

                        Sent from my Windows Phone

                        From: mike amundsen
                        Sent: 10/23/2011 7:02 AM
                        To: Glenn Block
                        Cc: rest-discuss; hypermedia-web@...
                        Subject: Re: [rest-discuss] Definition of a Hypermedia Client

                        Glenn:

                        are you indicating that you would prefer to use definition #1 as your "defintion of a hypermedia client" (along w/ something regarding starting URIs)?

                        mca
                        http://amundsen.com/blog/
                        http://twitter.com@mamund
                        http://mamund.com/foaf.rdf#me




                        On Sat, Oct 22, 2011 at 23:12, Glenn Block <glenn.block@...> wrote:
                        I owuld add one exception to 1, which is the application root as there needs to be some known uri which is the entry point of the application otherwise you'll never access the application in the first place....


                        On Sat, Oct 22, 2011 at 8:08 PM, Glenn Block <glenn.block@...> wrote:
                        Great to see you fleshing this out. In terms of prior art, Darrel has done a bunch of work around hypermedia clients with his Rest Agent stuff.
                         
                        A few other thoughts
                         
                        1. A hypermedia client is not coupled to the uri space of the application / does not contain hard coded logic for uris on the server.
                         
                        2. A hypermedia client ignores hypermedia controls that it cannot handle / it does not break by the presence of new hypermedia controls.
                         
                        3. A hypermedia client advances application state by choosing from available hypermedia controls in server responses.


                         
                        On Fri, Jun 10, 2011 at 1:44 PM, mike amundsen <mamund@...> wrote:
                         

                        ** cross-posted **

                        I'm contemplating a working definition for a "Hypermedia Client." Here are my first attempts:

                        1 - "A Hypermedia Client supports advancing it's own application state based on application control information supplied in server responses."

                        2 - "A Hypermedia Client supports advancing application state by sending requests to servers based on application control information supplied in server responses."

                        3 - "A Hypermedia Client supports advancing application state by sending requests to servers based on application control information embedded within, or as a layer above, the presentation of information supplied in server responses."

                        The germ of this definition is loosely based on a Fielding's description of "Distributed Hypermedia"[1]

                        The point of this exercise is:
                        1) Is there a generally agreed definition?
                        2) Can a definition be useful in evaluating/analyzing existing implementations? (e.g. "Is 'this' a hypermedia client?")
                        3) Can a definition be useful in creating new implementations that "meet" the definition? (e.g. "Here is what you need to build a hypermedia client....")

                        Any/all feedback is welcome.  Possibly there is "prior art" here of which I am unaware; please point me to any reference material you may think useful. Maybe you've gone through a similar process and would like to send along your experiences.

                        Thanks in advance.





                      • Tim Williams
                        On Sun, Oct 23, 2011 at 12:39 PM, bruce.krakower ... fwiw, yes, i think it s fair to say a new state transition offered by the server shouldn t break a
                        Message 11 of 22 , Oct 25, 2011
                        View Source
                        • 0 Attachment
                          On Sun, Oct 23, 2011 at 12:39 PM, bruce.krakower
                          <bruce.krakower@...> wrote:
                          >
                          > Regarding evolvability, can we really say if new hypermedia controls should or
                          > shouldn't "break" a hypermedia client? This seems to get a bit fuzzy when a new
                          > resource interaction may be required for a given application domain.

                          fwiw, yes, i think it's fair to say a new state transition offered by
                          the server shouldn't break a hypermedia client. but then, i also
                          agree with mnot's principle[1] and I think the two are related.

                          "there is an underlying principle to almost any kind of of versioning
                          on the Web; not breaking existing clients."

                          Thanks,
                          --tim

                          [1] - http://www.mnot.net/blog/2011/10/25/web_api_versioning_smackdown
                        • Erik Wilde
                          ... maybe include some recommendation to think about this when defining media types and link types, and to also document whether there are mustUnderstand or
                          Message 12 of 22 , Oct 25, 2011
                          View Source
                          • 0 Attachment
                            On 2011-10-25 04:15 , Tim Williams wrote:
                            > On Sun, Oct 23, 2011 at 12:39 PM, bruce.krakower <bruce.krakower@...> wrote:
                            >> Regarding evolvability, can we really say if new hypermedia controls should or
                            >> shouldn't "break" a hypermedia client? This seems to get a bit fuzzy when a new
                            >> resource interaction may be required for a given application domain.
                            > fwiw, yes, i think it's fair to say a new state transition offered by
                            > the server shouldn't break a hypermedia client. but then, i also
                            > agree with mnot's principle[1] and I think the two are related.
                            > "there is an underlying principle to almost any kind of of versioning
                            > on the Web; not breaking existing clients."

                            maybe include some recommendation to think about this when defining
                            media types and link types, and to also document whether there are
                            "mustUnderstand" or "mustIgnore" semantics at work for extensions?

                            cheers,

                            dret.
                          • Nick Gall
                            ... I would add another exception to (1): A hypermedia client IS coupled to the link relation uri space of the media type used (and possibly extended) by the
                            Message 13 of 22 , Oct 25, 2011
                            View Source
                            • 0 Attachment
                              On Sat, Oct 22, 2011 at 11:12 PM, Glenn Block <glenn.block@...> wrote:


                              I owuld add one exception to 1, which is the application root as there needs to be some known uri which is the entry point of the application otherwise you'll never access the application in the first place....

                              I would add another exception to (1):  A hypermedia client IS coupled to the link relation uri space of the media type used (and possibly extended) by the application. See my comment on mnot's blog post for more details: http://www.mnot.net/blog/2011/10/25/web_api_versioning_smackdown

                              You can shift tight coupling around, but you can't eliminate it...

                              -- Nick
                            • Mike Kelly
                              If the link relations are dereferenceable URIs, you can use HTTP to hint to clients about the freshness of the semantics (i.e. with Cache-Control, ETags, etc.)
                              Message 14 of 22 , Oct 25, 2011
                              View Source
                              • 0 Attachment
                                If the link relations are dereferenceable URIs, you can use HTTP to hint to clients about the freshness of the semantics (i.e. with Cache-Control, ETags, etc.)

                                Cheers,
                                Mike

                                On Tue, Oct 25, 2011 at 5:08 PM, Nick Gall <nick.gall@...> wrote:


                                On Sat, Oct 22, 2011 at 11:12 PM, Glenn Block <glenn.block@...> wrote:


                                I owuld add one exception to 1, which is the application root as there needs to be some known uri which is the entry point of the application otherwise you'll never access the application in the first place....

                                I would add another exception to (1):  A hypermedia client IS coupled to the link relation uri space of the media type used (and possibly extended) by the application. See my comment on mnot's blog post for more details: http://www.mnot.net/blog/2011/10/25/web_api_versioning_smackdown

                                You can shift tight coupling around, but you can't eliminate it...

                                -- Nick



                              • Nick Gall
                                ... Indeed. And that s a good practice. But it will only give you hints about the coupling and whether it is still intact . It won t prevent breaking the
                                Message 15 of 22 , Oct 25, 2011
                                View Source
                                • 0 Attachment
                                  On Tue, Oct 25, 2011 at 12:30 PM, Mike Kelly <mike@...> wrote:
                                  If the link relations are dereferenceable URIs, you can use HTTP to hint to clients about the freshness of the semantics (i.e. with Cache-Control, ETags, etc.)

                                  Indeed. And that's a good practice. But it will only give you "hints" about the coupling and whether it is still "intact". It won't prevent breaking the coupling if you change the semantics. And it won't prevent the need to create a new link relation namespace if you want to enable new semantics while leaving the old namespace with its semantics intact.

                                  -- Nick

                                • Mike Kelly
                                  ... It does prevent the need provided the changes aren t breaking. Is that not enough? Cheers, Mike
                                  Message 16 of 22 , Oct 25, 2011
                                  View Source
                                  • 0 Attachment
                                    On Tue, Oct 25, 2011 at 5:43 PM, Nick Gall <nick.gall@...> wrote:
                                    > On Tue, Oct 25, 2011 at 12:30 PM, Mike Kelly <mike@...> wrote:
                                    >>
                                    >> If the link relations are dereferenceable URIs, you can use HTTP to hint
                                    >> to clients about the freshness of the semantics (i.e. with Cache-Control,
                                    >> ETags, etc.)
                                    >
                                    > Indeed. And that's a good practice. But it will only give you "hints" about
                                    > the coupling and whether it is still "intact". It won't prevent breaking the
                                    > coupling if you change the semantics. And it won't prevent the need to
                                    > create a new link relation namespace if you want to enable new semantics
                                    > while leaving the old namespace with its semantics intact.

                                    It does prevent the need provided the changes aren't breaking.

                                    Is that not enough?

                                    Cheers,
                                    Mike
                                  • Nick Gall
                                    ... No. Inevitably, if the hypermedia interface is successful and evolves, some change WILL be breaking. That is the whole point of mnot s excellent blog post
                                    Message 17 of 22 , Oct 25, 2011
                                    View Source
                                    • 0 Attachment
                                      On Tue, Oct 25, 2011 at 12:54 PM, Mike Kelly <mike@...> wrote:
                                      On Tue, Oct 25, 2011 at 5:43 PM, Nick Gall <nick.gall@...> wrote:
                                      > On Tue, Oct 25, 2011 at 12:30 PM, Mike Kelly <mike@...> wrote:
                                      >>
                                      >> If the link relations are dereferenceable URIs, you can use HTTP to hint
                                      >> to clients about the freshness of the semantics (i.e. with Cache-Control,
                                      >> ETags, etc.)
                                      >
                                      > Indeed. And that's a good practice. But it will only give you "hints" about
                                      > the coupling and whether it is still "intact". It won't prevent breaking the
                                      > coupling if you change the semantics. And it won't prevent the need to
                                      > create a new link relation namespace if you want to enable new semantics
                                      > while leaving the old namespace with its semantics intact.

                                      It does prevent the need provided the changes aren't breaking.

                                      Is that not enough?

                                      No. Inevitably, if the hypermedia interface is successful and evolves, some change WILL be breaking. That is the whole point of mnot's excellent blog post on the subject.

                                      -- Nick
                                    • Mike Kelly
                                      ... Right, the point being it gets you far enough so as there s no need to be concerned about having to create an additional link relation for a breaking
                                      Message 18 of 22 , Oct 25, 2011
                                      View Source
                                      • 0 Attachment
                                        On Tue, Oct 25, 2011 at 6:08 PM, Nick Gall <nick.gall@...> wrote:
                                        > On Tue, Oct 25, 2011 at 12:54 PM, Mike Kelly <mike@...> wrote:
                                        >>
                                        >> On Tue, Oct 25, 2011 at 5:43 PM, Nick Gall <nick.gall@...> wrote:
                                        >> > On Tue, Oct 25, 2011 at 12:30 PM, Mike Kelly <mike@...> wrote:
                                        >> >>
                                        >> >> If the link relations are dereferenceable URIs, you can use HTTP to
                                        >> >> hint
                                        >> >> to clients about the freshness of the semantics (i.e. with
                                        >> >> Cache-Control,
                                        >> >> ETags, etc.)
                                        >> >
                                        >> > Indeed. And that's a good practice. But it will only give you "hints"
                                        >> > about
                                        >> > the coupling and whether it is still "intact". It won't prevent breaking
                                        >> > the
                                        >> > coupling if you change the semantics. And it won't prevent the need to
                                        >> > create a new link relation namespace if you want to enable new semantics
                                        >> > while leaving the old namespace with its semantics intact.
                                        >>
                                        >> It does prevent the need provided the changes aren't breaking.
                                        >>
                                        >> Is that not enough?
                                        >
                                        > No. Inevitably, if the hypermedia interface is successful and evolves, some
                                        > change WILL be breaking. That is the whole point of mnot's excellent blog
                                        > post on the subject.

                                        Right, the point being it gets you far enough so as there's no need to
                                        be concerned about having to create an additional link relation for a
                                        breaking change, as having to do so is reduced to the lowest rate
                                        realistic/possible for a machine-consumed application.

                                        On another note; I'm surprised nobody's preached the mystical
                                        evolvability-inducing powers of 'forms' yet - apparently they solve
                                        this problem. Or so we're told.. ;)

                                        Cheers,
                                        Mike
                                      • Will Hartung
                                        ... The forms offer insight in to what the server is expecting for a particular operation. The interface will evolve in both directions. On the server side, in
                                        Message 19 of 22 , Oct 25, 2011
                                        View Source
                                        • 0 Attachment
                                          On Tue, Oct 25, 2011 at 10:29 AM, Mike Kelly <mike@...> wrote:
                                          Right, the point being it gets you far enough so as there's no need to
                                          be concerned about having to create an additional link relation for a
                                          breaking change, as having to do so is reduced to the lowest rate
                                          realistic/possible for a machine-consumed application.

                                          On another note; I'm surprised nobody's preached the mystical
                                          evolvability-inducing powers of 'forms' yet - apparently they solve
                                          this problem. Or so we're told.. ;)

                                          The forms offer insight in to what the server is expecting for a particular operation.

                                          The interface will evolve in both directions. On the server side, in the number and variety of links that it publishes as the client navigates. Whether a client can actually recognize and support the new links is not really relevant. The clients (especially machine clients) will remain steadfast in their interpretation of the representation until a "breaking" event happens.

                                          This breaking event is either some underlying, foundation failure (i.e. the format has changed beyond recognition for the client), or its imposed externally upon the client by the clients controller (for example the want to now support some of this new functionality).

                                          Through inspection, a client can look at the resource representation and determine what links are supported by the server, and match that list to the understanding of the client, as in which of those links it knows how to follow based on their rels.

                                          From an input perspective, the FORM publishes the information that the server wants to know. The process for the client is the same. The client will have to evolve in order to handle any new form fields just like it would have to evolve to handle any new links that it discovers.  But the client will continue to process the "old way" until the breaking event occurs.

                                          In a space of several servers, using compatible representations, the use of the form can be used to allow, for example, a more sophisticated client to interact with a less sophisticated server.

                                          Consider the case of a purchasing agent wanting to forward credit card information. A modern server would likely want not just the normal CC info (number, name, exp date) but also that magic code on the back of the card. An older server may not require that extra code.

                                          A client that is capable and aware of that code would see that an older server is simply not asking for this information and will there for not provide it rather than just cramming it down the servers throat "because they all do this".

                                          In the end, the client needs to understand how to interpret what it sees in the payloads, and well as how to populate the forms that are requested by the servers. The advantage of the forms is that it lets the servers be reasonably explicit as to what it wants without having to rely on the client simply "knowing". With friendly clients and servers, this makes the both ends of the interface much more evolutionary, and uses in band information to manage this to boot.

                                          Regards,

                                          Will Hartung
                                          (willh@...)

                                        • Mike Kelly
                                          ... i.e. in this respect, forms achieve the same thing as link relations but in a more complicated way? ... The problem with this is that it can be handled
                                          Message 20 of 22 , Oct 25, 2011
                                          View Source
                                          • 0 Attachment
                                            On Tue, Oct 25, 2011 at 7:03 PM, Will Hartung <willh@...> wrote:
                                            >
                                            >
                                            > On Tue, Oct 25, 2011 at 10:29 AM, Mike Kelly <mike@...> wrote:
                                            >>
                                            >> Right, the point being it gets you far enough so as there's no need to
                                            >> be concerned about having to create an additional link relation for a
                                            >> breaking change, as having to do so is reduced to the lowest rate
                                            >> realistic/possible for a machine-consumed application.
                                            >>
                                            >> On another note; I'm surprised nobody's preached the mystical
                                            >> evolvability-inducing powers of 'forms' yet - apparently they solve
                                            >> this problem. Or so we're told.. ;)
                                            >
                                            > The forms offer insight in to what the server is expecting for a particular
                                            > operation.
                                            >
                                            > The interface will evolve in both directions. On the server side, in the
                                            > number and variety of links that it publishes as the client navigates.
                                            > Whether a client can actually recognize and support the new links is not
                                            > really relevant. The clients (especially machine clients) will remain
                                            > steadfast in their interpretation of the representation until a "breaking"
                                            > event happens.
                                            >
                                            > This breaking event is either some underlying, foundation failure (i.e. the
                                            > format has changed beyond recognition for the client), or its imposed
                                            > externally upon the client by the clients controller (for example the want
                                            > to now support some of this new functionality).
                                            >
                                            > Through inspection, a client can look at the resource representation and
                                            > determine what links are supported by the server, and match that list to the
                                            > understanding of the client, as in which of those links it knows how to
                                            > follow based on their rels.
                                            >
                                            > From an input perspective, the FORM publishes the information that the
                                            > server wants to know. The process for the client is the same. The client
                                            > will have to evolve in order to handle any new form fields just like it
                                            > would have to evolve to handle any new links that it discovers.  But the
                                            > client will continue to process the "old way" until the breaking event
                                            > occurs.

                                            i.e. in this respect, forms achieve the same thing as link relations
                                            but in a more complicated way?

                                            > In a space of several servers, using compatible representations, the use of
                                            > the form can be used to allow, for example, a more sophisticated client to
                                            > interact with a less sophisticated server.
                                            >
                                            > Consider the case of a purchasing agent wanting to forward credit card
                                            > information. A modern server would likely want not just the normal CC info
                                            > (number, name, exp date) but also that magic code on the back of the card.
                                            > An older server may not require that extra code.
                                            >
                                            > A client that is capable and aware of that code would see that an older
                                            > server is simply not asking for this information and will there for not
                                            > provide it rather than just cramming it down the servers throat "because
                                            > they all do this".

                                            The problem with this is that it can be handled trivially on the
                                            server side (by ignoring irrelevant parts of the client request), in
                                            contrast to the complexity introduced on the client side by requiring
                                            them to incorporate dynamic form interaction to their work flow.

                                            Most people want to make life as easy as possible for their clients.
                                            If there's a means to an ends resulting in less complexity for clients
                                            it's very likely that will get picked - and rightly so.

                                            > In the end, the client needs to understand how to interpret what it sees in
                                            > the payloads, and well as how to populate the forms that are requested by
                                            > the servers. The advantage of the forms is that it lets the servers be
                                            > reasonably explicit as to what it wants without having to rely on the client
                                            > simply "knowing". With friendly clients and servers, this makes the both
                                            > ends of the interface much more evolutionary, and uses in band information
                                            > to manage this to boot.

                                            I disagree that the result is much more evolutionary. Afaict, omitting
                                            and renaming the data produced by clients at run time is the extent of
                                            the additional capabilities forms introduce. As I said above, I'm
                                            unconvinced that the cost of adding significant additional
                                            requirements to interact with your application outweigh the benefits -
                                            particularly given that the benefits seem to be at best marginal, and
                                            at worst non-existent.

                                            Cheers,
                                            Mike
                                          • Glenn Block
                                            I say yes, it should not break the client. This is more than just Hypermedia it s a general principal applied to HTTP. If I introduce new hypermedia controls,
                                            Message 21 of 22 , Oct 25, 2011
                                            View Source
                                            • 0 Attachment
                                              I say yes, it should not break the client. This is more than just Hypermedia it's a general principal applied to HTTP. If I introduce new hypermedia controls, older clients should just ignore them.

                                              On Sun, Oct 23, 2011 at 9:39 AM, bruce.krakower <bruce.krakower@...> wrote:
                                               

                                              Regarding evolvability, can we really say if new hypermedia controls should or shouldn't "break" a hypermedia client? This seems to get a bit fuzzy when a new resource interaction may be required for a given application domain.


                                            • Sebastien Lambla
                                              Mike, you have a very restrictive or biased views on forms, that may have been induced by xforms or some other technology. At heart, a form is only a mean to
                                              Message 22 of 22 , Oct 26, 2011
                                              View Source
                                              • 0 Attachment
                                                Mike,

                                                you have a very restrictive or biased views on forms, that may have been induced by xforms or some other technology.

                                                At heart, a form is only a mean to say to a client "i'll let you know where you can put the data in that bit i give you", or sometimes "do as usual but start with this content", as well as some additional control data.

                                                I'd argue that introducing forms and clients that can process them is a more expensive solution that introduces an ability to change the server independently of the client, and removes some of the domain-specific modelling from the media type. Depending on your scenario that cost may be justified or not. HTML browsers have full justification for this, and if you disagree that HTML forms were a good thing then I'll just agree to disagree with you.

                                                I'll also disagree that implementing form-based interaction has to be complicated. Be it in a markup world or a json world, those things can be built and extended fairly cheaply, and that includes using a small subset of xforms as IanR has shown many times.

                                                Forms are a tool that has proven itself valuable for those that have implemented them, for their scenarios, and blanket statements are helping no one on this list or elsewhere implement anything that matches their needs any better.


                                                ________________________________________
                                                From: rest-discuss@yahoogroups.com [rest-discuss@yahoogroups.com] on behalf of Mike Kelly [mike@...]
                                                Sent: 25 October 2011 18:29
                                                To: Nick Gall
                                                Cc: Glenn Block; mike amundsen; rest-discuss; hypermedia-web@...
                                                Subject: Re: [rest-discuss] Definition of a Hypermedia Client

                                                On Tue, Oct 25, 2011 at 6:08 PM, Nick Gall <nick.gall@...> wrote:
                                                > On Tue, Oct 25, 2011 at 12:54 PM, Mike Kelly <mike@...> wrote:
                                                >>
                                                >> On Tue, Oct 25, 2011 at 5:43 PM, Nick Gall <nick.gall@...> wrote:
                                                >> > On Tue, Oct 25, 2011 at 12:30 PM, Mike Kelly <mike@...> wrote:
                                                >> >>
                                                >> >> If the link relations are dereferenceable URIs, you can use HTTP to
                                                >> >> hint
                                                >> >> to clients about the freshness of the semantics (i.e. with
                                                >> >> Cache-Control,
                                                >> >> ETags, etc.)
                                                >> >
                                                >> > Indeed. And that's a good practice. But it will only give you "hints"
                                                >> > about
                                                >> > the coupling and whether it is still "intact". It won't prevent breaking
                                                >> > the
                                                >> > coupling if you change the semantics. And it won't prevent the need to
                                                >> > create a new link relation namespace if you want to enable new semantics
                                                >> > while leaving the old namespace with its semantics intact.
                                                >>
                                                >> It does prevent the need provided the changes aren't breaking.
                                                >>
                                                >> Is that not enough?
                                                >
                                                > No. Inevitably, if the hypermedia interface is successful and evolves, some
                                                > change WILL be breaking. That is the whole point of mnot's excellent blog
                                                > post on the subject.

                                                Right, the point being it gets you far enough so as there's no need to
                                                be concerned about having to create an additional link relation for a
                                                breaking change, as having to do so is reduced to the lowest rate
                                                realistic/possible for a machine-consumed application.

                                                On another note; I'm surprised nobody's preached the mystical
                                                evolvability-inducing powers of 'forms' yet - apparently they solve
                                                this problem. Or so we're told.. ;)

                                                Cheers,
                                                Mike


                                                ------------------------------------

                                                Yahoo! Groups Links
                                              Your message has been successfully submitted and would be delivered to recipients shortly.