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

conneg considered harmful

Expand Messages
  • Eric J. Bowman
    Catching up on http-wg, I came across this Roy quote: Regarding proactive negotiation in HTTP/2, I ll note that Waka strips all negotiation fields. I find
    Message 1 of 20 , Feb 13, 2013
    View Source
    • 0 Attachment
      Catching up on http-wg, I came across this Roy quote:

      "Regarding proactive negotiation in HTTP/2, I'll note that Waka
      strips all negotiation fields. I find the entire feature revolting,
      from every architectural perspective, and would take the opportunity
      of 2.x to remove it entirely."

      http://lists.w3.org/Archives/Public/ietf-http-wg/2013JanMar/0286.html

      I'm not seeing how a resource/representation architecture gets around
      needing a feature like conneg, was hoping maybe Roy could enlighten us?

      -Eric
    • Eric J. Bowman
      ... Would be nice to have some links, such discussions have eluded me. My apologies for overreacting, I took Roy s meaning as an argument against the late
      Message 2 of 20 , Feb 13, 2013
      View Source
      • 0 Attachment
        Mark Baker wrote:
        >
        > There are multiple forms of conneg and I think Roy has been pretty
        > clear about his disdain for server driven. Larry Masinter even
        > apologized in recent years for pushing for it back in the day.
        >

        Would be nice to have some links, such discussions have eluded me. My
        apologies for overreacting, I took Roy's meaning as an argument against
        the late binding of representation to resource altogether, as I lacked
        such context.

        >
        > Besides, client driven uses hypermedia so is way more RESTful.
        >

        Adding a round-trip, unless there's some way to make user preferences
        "sticky" for subsequent requests (like negotiation headers). Leading to
        sessions, at least as far as HTTP 1.1's concerned, so "more RESTful" is
        debatable as to real-world implementation. But, I see where other
        protocols could do things differently, avoiding such results.

        -Eric
      • Peter Williams
        Eric, That is an interesting quote. I have occasionally heard unsubstantiated claims regarding the badness of accept header based content negotiation. It is
        Message 3 of 20 , Feb 15, 2013
        View Source
        • 0 Attachment
          Eric,

          That is an interesting quote. I have occasionally heard
          unsubstantiated claims regarding the badness of accept header based
          content negotiation. It is interesting that Roy perceives it as
          "revolting".

          Personally, i rather like it but perhaps i am missing something
          important. I'd definitely like to hear someone (or multiple someones)
          actually articulate what they perceive as problematic about it. So far
          i don't recall ever reading a discussion of the downsides that got
          beyond "i don't like it" or "it is hard for me to implement" (neither
          of which resonate with me).

          On Wed, Feb 13, 2013 at 9:04 AM, Eric J. Bowman <eric@...> wrote:
          > Mark Baker wrote:
          >>
          >> Besides, client driven uses hypermedia so is way more RESTful.

          Mark, can you explain a bit more why you think this? It is not clear
          to me why avoiding this particular part of http's uniform interface
          would make a client more RESTful.

          Peter
          barelyenough.org
        • Alan Dean
          Perhaps it is worth referencing some other other Fielding quotes on the subject: https://delicious.com/alan.dean/Roy.Fielding+conneg Regards, Alan Dean
          Message 4 of 20 , Feb 15, 2013
          View Source
          • 0 Attachment
            Perhaps it is worth referencing some other other Fielding quotes on the subject:


            Regards,
            Alan Dean


            On Fri, Feb 15, 2013 at 8:21 PM, Peter Williams <pezra@...> wrote:
             

            Eric,

            That is an interesting quote. I have occasionally heard
            unsubstantiated claims regarding the badness of accept header based
            content negotiation. It is interesting that Roy perceives it as
            "revolting".

            Personally, i rather like it but perhaps i am missing something
            important. I'd definitely like to hear someone (or multiple someones)
            actually articulate what they perceive as problematic about it. So far
            i don't recall ever reading a discussion of the downsides that got
            beyond "i don't like it" or "it is hard for me to implement" (neither
            of which resonate with me).



            On Wed, Feb 13, 2013 at 9:04 AM, Eric J. Bowman eric@...> wrote:
            > Mark Baker wrote:
            >>
            >> Besides, client driven uses hypermedia so is way more RESTful.

            Mark, can you explain a bit more why you think this? It is not clear
            to me why avoiding this particular part of http's uniform interface
            would make a client more RESTful.

            Peter
            barelyenough.org


          • Peter Williams
            Most of those don t talk about why using content negotiation is bad in general. Instead they talk about how truly different resources should have their own
            Message 5 of 20 , Feb 15, 2013
            View Source
            • 0 Attachment

              Most of those don't talk about why using content negotiation is bad in general.  Instead they talk about how truly different resources should have their own uris even if they are variants of one another (eg articles about the same subject written in different human languages). That seems very reasonable.  However, those arguments don't apply to situations where multiple, truly mechanically translatable, representations of a single resource exist.

              One of those mention that conneg has a negative effect on caching. Is being harder to cache the only ill effect of sever driven conneg?

              Peter
              Barelyenough.org

              On Feb 15, 2013 3:31 PM, "Alan Dean" <alan.dean@...> wrote:
              Perhaps it is worth referencing some other other Fielding quotes on the subject:


              Regards,
              Alan Dean


              On Fri, Feb 15, 2013 at 8:21 PM, Peter Williams <pezra@...> wrote:
               

              Eric,

              That is an interesting quote. I have occasionally heard
              unsubstantiated claims regarding the badness of accept header based
              content negotiation. It is interesting that Roy perceives it as
              "revolting".

              Personally, i rather like it but perhaps i am missing something
              important. I'd definitely like to hear someone (or multiple someones)
              actually articulate what they perceive as problematic about it. So far
              i don't recall ever reading a discussion of the downsides that got
              beyond "i don't like it" or "it is hard for me to implement" (neither
              of which resonate with me).



              On Wed, Feb 13, 2013 at 9:04 AM, Eric J. Bowman eric@...> wrote:
              > Mark Baker wrote:
              >>
              >> Besides, client driven uses hypermedia so is way more RESTful.

              Mark, can you explain a bit more why you think this? It is not clear
              to me why avoiding this particular part of http's uniform interface
              would make a client more RESTful.

              Peter
              barelyenough.org


            • Mike Schinkel
              ... Here are just some additional references about content negotiation: http://trac.tools.ietf.org/wg/httpbis/trac/ticket/81
              Message 6 of 20 , Feb 15, 2013
              View Source
              • 0 Attachment
                On Feb 16, 2013, at 1:01 AM, Peter Williams <pezra@...> wrote:
                Most of those don't talk about why using content negotiation is bad in general.  Instead they talk about how truly different resources should have their own uris even if they are variants of one another (eg articles about the same subject written in different human languages). That seems very reasonable.  However, those arguments don't apply to situations where multiple, truly mechanically translatable, representations of a single resource exist.

                One of those mention that conneg has a negative effect on caching. Is being harder to cache the only ill effect of sever driven conneg?

                Here are just some additional references about content negotiation:


                There are numerous references that I found while searching to conneg being a "bad idea but okay in some contexts" but AFAICF no description of use-cases for which some say it does make sense.  

                -Mike



                On Feb 16, 2013, at 1:01 AM, Peter Williams <pezra@...> wrote:

                 

                Most of those don't talk about why using content negotiation is bad in general.  Instead they talk about how truly different resources should have their own uris even if they are variants of one another (eg articles about the same subject written in different human languages). That seems very reasonable.  However, those arguments don't apply to situations where multiple, truly mechanically translatable, representations of a single resource exist.

                One of those mention that conneg has a negative effect on caching. Is being harder to cache the only ill effect of sever driven conneg?

                Peter
                Barelyenough.org

                On Feb 15, 2013 3:31 PM, "Alan Dean" <alan.dean@...> wrote:
                Perhaps it is worth referencing some other other Fielding quotes on the subject:


                Regards,
                Alan Dean


                On Fri, Feb 15, 2013 at 8:21 PM, Peter Williams <pezra@...> wrote:
                 

                Eric,

                That is an interesting quote. I have occasionally heard
                unsubstantiated claims regarding the badness of accept header based
                content negotiation. It is interesting that Roy perceives it as
                "revolting".

                Personally, i rather like it but perhaps i am missing something
                important. I'd definitely like to hear someone (or multiple someones)
                actually articulate what they perceive as problematic about it. So far
                i don't recall ever reading a discussion of the downsides that got
                beyond "i don't like it" or "it is hard for me to implement" (neither
                of which resonate with me).



                On Wed, Feb 13, 2013 at 9:04 AM, Eric J. Bowman eric@...> wrote:
                > Mark Baker wrote:
                >>
                >> Besides, client driven uses hypermedia so is way more RESTful.

                Mark, can you explain a bit more why you think this? It is not clear
                to me why avoiding this particular part of http's uniform interface
                would make a client more RESTful.

                Peter
                barelyenough.org




              • Alan Dean
                To be clear what Roy actually said was In general, I avoid content negotiation *without redirects* like the plague because of its effect on caching. *(my
                Message 7 of 20 , Feb 16, 2013
                View Source
                • 0 Attachment
                  To be clear what Roy actually said was "In general, I avoid content negotiation without redirects like the plague because of its effect on caching." (my emphasis)

                  Regards,
                  Alan Dean


                  On Sat, Feb 16, 2013 at 6:01 AM, Peter Williams <pezra@...> wrote:

                  Most of those don't talk about why using content negotiation is bad in general.  Instead they talk about how truly different resources should have their own uris even if they are variants of one another (eg articles about the same subject written in different human languages). That seems very reasonable.  However, those arguments don't apply to situations where multiple, truly mechanically translatable, representations of a single resource exist.

                  One of those mention that conneg has a negative effect on caching. Is being harder to cache the only ill effect of sever driven conneg?

                  Peter
                  Barelyenough.org

                  On Feb 15, 2013 3:31 PM, "Alan Dean" <alan.dean@...> wrote:
                  Perhaps it is worth referencing some other other Fielding quotes on the subject:


                  Regards,
                  Alan Dean


                  On Fri, Feb 15, 2013 at 8:21 PM, Peter Williams <pezra@...> wrote:
                   

                  Eric,

                  That is an interesting quote. I have occasionally heard
                  unsubstantiated claims regarding the badness of accept header based
                  content negotiation. It is interesting that Roy perceives it as
                  "revolting".

                  Personally, i rather like it but perhaps i am missing something
                  important. I'd definitely like to hear someone (or multiple someones)
                  actually articulate what they perceive as problematic about it. So far
                  i don't recall ever reading a discussion of the downsides that got
                  beyond "i don't like it" or "it is hard for me to implement" (neither
                  of which resonate with me).



                  On Wed, Feb 13, 2013 at 9:04 AM, Eric J. Bowman eric@...> wrote:
                  > Mark Baker wrote:
                  >>
                  >> Besides, client driven uses hypermedia so is way more RESTful.

                  Mark, can you explain a bit more why you think this? It is not clear
                  to me why avoiding this particular part of http's uniform interface
                  would make a client more RESTful.

                  Peter
                  barelyenough.org



                • Glenn Block
                  Hello folks, been a long time! A very interesting and educational discussion indeed. Previously I have pushed quite heavily the support of server-driven
                  Message 8 of 20 , May 21, 2013
                  View Source
                  • 0 Attachment
                    Hello folks, been a long time!

                    A very interesting and educational discussion indeed. 

                    Previously I have pushed quite heavily the support of server-driven conneg, which is something we enable quite easily in ASP.NET Web API though without redirects.

                    It's possible to return a redirect, but that requires the user to do the heavy lifting. 

                    Can someone elaborate a bit more on the harms of not doing the redirect. I read through the different threads, but having a concise summary would be valuable.

                    A different question this brings up is the concern of costs associated with doing this in particular for a cloud-hosted deployment where each request costs money / compute hours. 

                    • Does adding in this redirect mean there's any significant cost increase? If you are talking about secure or data that is dynamically generated then a cache may not necessarily help offset that.
                    • Does the benefit outweight the cost in these cases?
                    I am curious what folks on the list are doing with regards to APIs deployed in the cloud.

                    Thanks!
                    Glenn






                    On Sat, Feb 16, 2013 at 2:01 AM, Alan Dean <alan.dean@...> wrote:
                     

                    To be clear what Roy actually said was "In general, I avoid content negotiation without redirects like the plague because of its effect on caching." (my emphasis)


                    Regards,
                    Alan Dean


                    On Sat, Feb 16, 2013 at 6:01 AM, Peter Williams <pezra@...> wrote:

                    Most of those don't talk about why using content negotiation is bad in general.  Instead they talk about how truly different resources should have their own uris even if they are variants of one another (eg articles about the same subject written in different human languages). That seems very reasonable.  However, those arguments don't apply to situations where multiple, truly mechanically translatable, representations of a single resource exist.

                    One of those mention that conneg has a negative effect on caching. Is being harder to cache the only ill effect of sever driven conneg?

                    Peter
                    Barelyenough.org

                    On Feb 15, 2013 3:31 PM, "Alan Dean" <alan.dean@...> wrote:
                    Perhaps it is worth referencing some other other Fielding quotes on the subject:


                    Regards,
                    Alan Dean


                    On Fri, Feb 15, 2013 at 8:21 PM, Peter Williams <pezra@...> wrote:
                     

                    Eric,

                    That is an interesting quote. I have occasionally heard
                    unsubstantiated claims regarding the badness of accept header based
                    content negotiation. It is interesting that Roy perceives it as
                    "revolting".

                    Personally, i rather like it but perhaps i am missing something
                    important. I'd definitely like to hear someone (or multiple someones)
                    actually articulate what they perceive as problematic about it. So far
                    i don't recall ever reading a discussion of the downsides that got
                    beyond "i don't like it" or "it is hard for me to implement" (neither
                    of which resonate with me).



                    On Wed, Feb 13, 2013 at 9:04 AM, Eric J. Bowman eric@...> wrote:
                    > Mark Baker wrote:
                    >>
                    >> Besides, client driven uses hypermedia so is way more RESTful.

                    Mark, can you explain a bit more why you think this? It is not clear
                    to me why avoiding this particular part of http's uniform interface
                    would make a client more RESTful.

                    Peter
                    barelyenough.org




                  • Glenn Block
                    Question, what about Content-Location? Isn t this header specifically there to inform the client / caches even if a negotiated representation was returned,
                    Message 9 of 20 , May 22, 2013
                    View Source
                    • 0 Attachment
                      Question, what about Content-Location? Isn't this header specifically there to inform the client / caches even if a negotiated representation was returned, what the negotiated resource Uri is?


                      On Tue, May 21, 2013 at 9:12 PM, Glenn Block <glenn.block@...> wrote:
                      Hello folks, been a long time!

                      A very interesting and educational discussion indeed. 

                      Previously I have pushed quite heavily the support of server-driven conneg, which is something we enable quite easily in ASP.NET Web API though without redirects.

                      It's possible to return a redirect, but that requires the user to do the heavy lifting. 

                      Can someone elaborate a bit more on the harms of not doing the redirect. I read through the different threads, but having a concise summary would be valuable.

                      A different question this brings up is the concern of costs associated with doing this in particular for a cloud-hosted deployment where each request costs money / compute hours. 

                      • Does adding in this redirect mean there's any significant cost increase? If you are talking about secure or data that is dynamically generated then a cache may not necessarily help offset that.
                      • Does the benefit outweight the cost in these cases?
                      I am curious what folks on the list are doing with regards to APIs deployed in the cloud.

                      Thanks!
                      Glenn






                      On Sat, Feb 16, 2013 at 2:01 AM, Alan Dean <alan.dean@...> wrote:
                       

                      To be clear what Roy actually said was "In general, I avoid content negotiation without redirects like the plague because of its effect on caching." (my emphasis)


                      Regards,
                      Alan Dean


                      On Sat, Feb 16, 2013 at 6:01 AM, Peter Williams <pezra@...> wrote:

                      Most of those don't talk about why using content negotiation is bad in general.  Instead they talk about how truly different resources should have their own uris even if they are variants of one another (eg articles about the same subject written in different human languages). That seems very reasonable.  However, those arguments don't apply to situations where multiple, truly mechanically translatable, representations of a single resource exist.

                      One of those mention that conneg has a negative effect on caching. Is being harder to cache the only ill effect of sever driven conneg?

                      Peter
                      Barelyenough.org

                      On Feb 15, 2013 3:31 PM, "Alan Dean" <alan.dean@...> wrote:
                      Perhaps it is worth referencing some other other Fielding quotes on the subject:


                      Regards,
                      Alan Dean


                      On Fri, Feb 15, 2013 at 8:21 PM, Peter Williams <pezra@...> wrote:
                       

                      Eric,

                      That is an interesting quote. I have occasionally heard
                      unsubstantiated claims regarding the badness of accept header based
                      content negotiation. It is interesting that Roy perceives it as
                      "revolting".

                      Personally, i rather like it but perhaps i am missing something
                      important. I'd definitely like to hear someone (or multiple someones)
                      actually articulate what they perceive as problematic about it. So far
                      i don't recall ever reading a discussion of the downsides that got
                      beyond "i don't like it" or "it is hard for me to implement" (neither
                      of which resonate with me).



                      On Wed, Feb 13, 2013 at 9:04 AM, Eric J. Bowman eric@...> wrote:
                      > Mark Baker wrote:
                      >>
                      >> Besides, client driven uses hypermedia so is way more RESTful.

                      Mark, can you explain a bit more why you think this? It is not clear
                      to me why avoiding this particular part of http's uniform interface
                      would make a client more RESTful.

                      Peter
                      barelyenough.org





                    • Darrel Miller
                      For the record, here is a link [1] to Larry Masinter s apology for pushing accept header based conneg and his suggestion that it be deprecated. It is sad that
                      Message 10 of 20 , Jun 7, 2013
                      View Source
                      • 0 Attachment
                        For the record, here is a link [1] to Larry Masinter's apology for pushing accept header based conneg and his suggestion that it be deprecated.  It is sad that this email is from 2006 and yet here we are still...
                         
                         Darrel
                         
                      • Darrel Miller
                        ...and just a couple more notes. The last few updates to the Httpbis spec added some clarification to the subject including these paragraphs. Proactive
                        Message 11 of 20 , Jun 7, 2013
                        View Source
                        • 0 Attachment
                          ...and just a couple more notes.  The last few updates to the Httpbis spec added some clarification to the subject including these paragraphs.
                           
                          Proactive negotiation has serious disadvantages:
                          
                             o  It is impossible for the server to accurately determine what might
                                be "best" for any given user, since that would require complete
                                knowledge of both the capabilities of the user agent and the
                                intended use for the response (e.g., does the user want to view it
                                on screen or print it on paper?);
                          
                             o  Having the user agent describe its capabilities in every request
                                can be both very inefficient (given that only a small percentage
                                of responses have multiple representations) and a potential risk
                                to the user's privacy;
                          
                             o  It complicates the implementation of an origin server and the
                                algorithms for generating responses to a request; and,
                          
                             o  It limits the reusability of responses for shared caching.
                          

                           

                           
                          In is also interesting to note that Fielding is working on a ID that describes a replacement for the vary header that solves some of the issues relating to caching negotiated responses.
                           

                          Darrel


                          On Fri, Jun 7, 2013 at 8:39 AM, Darrel Miller <darrel.miller@...> wrote:
                          For the record, here is a link [1] to Larry Masinter's apology for pushing accept header based conneg and his suggestion that it be deprecated.  It is sad that this email is from 2006 and yet here we are still...
                           
                           Darrel
                           

                        • mike amundsen
                          first, i find it instructive that the thread you cite started with an effort to register a media type that had a version number in the identifier! second, it s
                          Message 12 of 20 , Jun 7, 2013
                          View Source
                          • 0 Attachment
                            first, i find it instructive that the thread you cite started with an effort to register a media type that had a version number in the identifier!

                            second, it's not clear to me whether Larry is apologizing for the conneg implementation details or the concept of conneg itself. and i see nothing here regarding client-driven conneg,

                            FWIW, HTTP is the only app-level protocol that provides the ability to negotiation for representation details including media type, charset, language, encoding, and even ranges. No doubt some have proved more effective than others. I think the ability to negotiate for representations is an important part of the spec and while i'm open to new ways to implement the feature, i don't think it wise to drop it.

                            as for "deprecating" as LM mentions, there is no such thing on "the Web." once spec'd it will always remain. we can discourage the use of some aspect of the spec, but removing it is neither advisable or likely.

                            BTW - i'd be happy to see user-agents support client-driven negotiation. i used to think this meant common browsers MUST be the leaders for a feature like this. but recently i've started to think that native-built mobile clients could start to turn the tide on what features show up in the pipeline.



                            On Fri, Jun 7, 2013 at 8:39 AM, Darrel Miller <darrel.miller@...> wrote:


                            For the record, here is a link [1] to Larry Masinter's apology for pushing accept header based conneg and his suggestion that it be deprecated.  It is sad that this email is from 2006 and yet here we are still...
                             
                             Darrel
                             



                          • Robert Brewer
                            ... It s clear if you read the whole thread. Larry retreats a bit to Javascript detection does a better job than Accept , admitting that Accept-Language is
                            Message 13 of 20 , Jun 7, 2013
                            View Source
                            • 0 Attachment
                              Darrel Miller wrote:
                              > For the record, here is a link [1] to Larry Masinter's
                              > apology for pushing accept header based conneg and his
                              > suggestion that it be deprecated. It is sad that this
                              > email is from 2006 and yet here we are still...

                              and mike amundsen replied:
                              > second, it's not clear to me whether Larry is apologizing
                              > for the conneg implementation details or the concept of
                              > conneg itself. and i see nothing here regarding
                              > client-driven conneg,

                              It's clear if you read the whole thread. Larry retreats a bit to "Javascript detection does a better job than Accept", admitting that Accept-Language is doing a fine job, and Accept itself might be OK in non-scripted payloads/clients.


                              Robert Brewer
                              fumanchu@...
                            • Eric J. Bowman
                              ... +1, and +1 to [1] and [2] while I m at it... Browsers are truly becoming their own, undefined architecture. REST may become unfeasible as a model for
                              Message 14 of 20 , Jun 7, 2013
                              View Source
                              • 0 Attachment
                                >
                                > BTW - i'd be happy to see user-agents support client-driven
                                > negotiation. i used to think this meant common browsers MUST be the
                                > leaders for a feature like this. but recently i've started to think
                                > that native-built mobile clients could start to turn the tide on what
                                > features show up in the pipeline.
                                >

                                +1, and +1 to [1] and [2] while I'm at it...

                                Browsers are truly becoming their own, undefined architecture. REST
                                may become unfeasible as a model for browser-based system performance,
                                which hardly means it won't continue to be the ideal, or that resources
                                will cease to exist as an abstract concept even if TAG replaces the term
                                in AWWW v2.

                                It merely opens the door for exactly what Mike just said -- leadership
                                on features/performance passes to native apps which aren't precluded
                                from leveraging REST to the hilt. The problem with declaring REST a
                                dinosaur (and deprecating application/xhtml+xml, removing Content-Type,
                                ignoring interoperability in favor of versionless "standards" etc.), is
                                it's still adapted to its environment -- HTTP over an anarchic, end-to-
                                end Internet, no habitat loss I can see...

                                Personally, I find the UX I'm subjected to on most every site could
                                still benefit from the developers undertaking to learn a bit about
                                REST even though everything about it except buzzwordiness has gone out
                                of vogue lately, to the point I find it pointless to continue to comment
                                on www-tag, particularly as my concern about updating HttpRange-14 not
                                only wasn't responded to but judging by the minutes, wasn't even
                                considered. It's been shown that sniffing binaries is a security hole,
                                but I guess we'll just put out those fires as they flare up for the
                                sake of not having to talk about resources/representations even though
                                it's also been shown [3] that resources exist.

                                </rant>

                                -Eric

                                [1]
                                http://lists.w3.org/Archives/Public/ietf-http-wg/2013AprJun/0001.html
                                [2] http://lists.w3.org/Archives/Public/www-tag/2013Jun/0014.html
                                [3] http://lists.w3.org/Archives/Public/www-tag/2013Jun/0028.html
                              • Mike Kelly
                                ... What do you mean by undefined ? Running code has definitive behaviour: http://caniuse.com/ What is it, specifically, that you feel may be about to render
                                Message 15 of 20 , Jun 8, 2013
                                View Source
                                • 0 Attachment



                                  On Fri, Jun 7, 2013 at 10:17 PM, Eric J. Bowman <eric@...> wrote:
                                   

                                  >
                                  > BTW - i'd be happy to see user-agents support client-driven
                                  > negotiation. i used to think this meant common browsers MUST be the
                                  > leaders for a feature like this. but recently i've started to think
                                   > that native-built mobile clients could start to turn the tide on what
                                  > features show up in the pipeline.
                                  >

                                  +1, and +1 to [1] and [2] while I'm at it...

                                  Browsers are truly becoming their own, undefined architecture. REST
                                  may become unfeasible as a model for browser-based system performance,
                                  which hardly means it won't continue to be the ideal, or that resources
                                  will cease to exist as an abstract concept even if TAG replaces the term
                                  in AWWW v2.

                                  What do you mean by 'undefined'? Running code has definitive behaviour: http://caniuse.com/

                                  What is it, specifically, that you feel may be about to render browsers infeasible as the basis for a RESTful system?

                                  Is there anything missing that would make it feasible and if so why is it missing? e.g. why did the efforts to introduce PUT and DELETE to <form> fail?

                                  fwiw, I am -1 to this idea of trying to "defend REST" by pursuing a competing platform on 'native mobile'. It seems like a huge waste of time.. How can you do this without essentially just reproducing something that does what a browser does already? Surely, it would be better to direct all that energy towards improving the trajectory of this new, "living" browser platform? Even if that is a hard slog, it's probably the most likely way of getting the outcome you want.

                                  Cheers,
                                  M
                                • Eric J. Bowman
                                  ... Like interoperability with things that aren t browsers, or which follow RFC 3986? Highly doubtful. -Eric
                                  Message 16 of 20 , Jun 8, 2013
                                  View Source
                                  • 0 Attachment
                                    Mike Kelly wrote:
                                    >
                                    > Even if that is a hard slog, it's probably the most likely way of
                                    > getting the outcome you want.
                                    >

                                    Like interoperability with things that aren't browsers, or which follow
                                    RFC 3986? Highly doubtful.

                                    -Eric
                                  • Eric J. Bowman
                                    ... REST is a defined architectural style. The link you ve posted is all about where a set of moving-goalpost features overlap at a moment in time, which is
                                    Message 17 of 20 , Jun 8, 2013
                                    View Source
                                    • 0 Attachment
                                      Mike Kelly wrote:
                                      >
                                      > What do you mean by 'undefined'? Running code has definitive
                                      > behaviour: http://caniuse.com/
                                      >

                                      REST is a defined architectural style. The link you've posted is all
                                      about where a set of moving-goalpost features overlap at a moment in
                                      time, which is hardly the same thing. While system behavior may be
                                      definable, it's a by-product of the design process, as opposed to goals
                                      used to guide the design process. What I mean by defined architecture
                                      would be some sort of Taylor-school definition of just what's trying to
                                      be accomplished, like REST was the model for the move to HTTP 1.1.

                                      >
                                      > What is it, specifically, that you feel may be about to render
                                      > browsers infeasible as the basis for a RESTful system?
                                      >

                                      Silent error correction, content sniffing being used as a reason to
                                      deprecate Content-Type, any number of RFC 3986 violations -- we're
                                      clearly off into uncharted territory with little or no resemblance to
                                      REST, and I've just scratched the surface. What else to make of this
                                      move to just not mention "resource" and redefine URIs to identify
                                      either documents or services? How is it possible to be more anti-REST?

                                      >
                                      > Is there anything missing that would make it feasible and if so why
                                      > is it missing? e.g. why did the efforts to introduce PUT and DELETE
                                      > to <form> fail?
                                      >

                                      What's missing is browser-vendor knowledge of architecture, or any HTTP/
                                      URI interoperability issues not involving browsers. I won't speculate
                                      as to why, it's not as if Roy didn't used to waste his breath explaining
                                      to these people the finer points of why ad-hoc changes to WebArch are
                                      short-sighted. Sufficient explanation to me of why no PUT, DELETE,
                                      Xforms, list goes on -- not to mention feature removal...

                                      Clearly, the future of REST no longer lies with the browser. My status
                                      nowadays is "on sabbatical" to recover my health, after recently "re-
                                      homing" the last of my clients -- that one since 1994 which is how long
                                      I've been developing Web sites for consumption in browsers. I have a 9-
                                      week-old Alaskan Malamute to help me drop at least a couple stone before
                                      I return, may take a few years.

                                      I'll continue to participate here, but when I return to Web development
                                      it certainly looks like I'll be forsaking the browser for the native
                                      app, where I can continue to bring my clients positive returns on their
                                      online investments by leveraging REST to deal with the realities of the
                                      netowrk currently being denied by the browser vendors.

                                      Should be interesting to watch, but the "new direction" has caused me
                                      to pull my horse from the race; I no longer have any vested interest
                                      nor do I care about the future of browsers. Only a sense that we'll be
                                      cleaning up the mess for a long time to come -- corporate production
                                      cycles, marketing imperatives, and bottom lines are no way to guide
                                      the Web's architectural development, and this era can't end well.

                                      -Eric
                                    • Mike Kelly
                                      ... Ok, I disagree. Afaik, there isn t a more feasible course of action, and it sounds as if you are not going to invest any time on an alternative in the
                                      Message 18 of 20 , Jun 8, 2013
                                      View Source
                                      • 0 Attachment
                                        On Sat, Jun 8, 2013 at 1:07 PM, Eric J. Bowman <eric@...> wrote:
                                        > Mike Kelly wrote:
                                        >>
                                        >> Even if that is a hard slog, it's probably the most likely way of
                                        >> getting the outcome you want.
                                        >>
                                        >
                                        > Like interoperability with things that aren't browsers, or which follow
                                        > RFC 3986? Highly doubtful.

                                        Ok, I disagree. Afaik, there isn't a more feasible course of action,
                                        and it sounds as if you are not going to invest any time on an
                                        alternative in the foreseeable future.

                                        I do share some of your concern though, so it would be intriguing to
                                        hear some specifics on what those alternatives might (or already do)
                                        look like... mamund? :)


                                        On Sat, Jun 8, 2013 at 2:02 PM, Eric J. Bowman <eric@...> wrote:
                                        > Mike Kelly wrote:
                                        >>
                                        >> What do you mean by 'undefined'? Running code has definitive
                                        >> behaviour: http://caniuse.com/
                                        >>
                                        >
                                        > REST is a defined architectural style. The link you've posted is all
                                        > about where a set of moving-goalpost features overlap at a moment in
                                        > time, which is hardly the same thing. While system behavior may be
                                        > definable, it's a by-product of the design process, as opposed to goals
                                        > used to guide the design process. What I mean by defined architecture
                                        > would be some sort of Taylor-school definition of just what's trying to
                                        > be accomplished, like REST was the model for the move to HTTP 1.1.
                                        >
                                        >>
                                        >> What is it, specifically, that you feel may be about to render
                                        >> browsers infeasible as the basis for a RESTful system?
                                        >>
                                        >
                                        > Silent error correction, content sniffing being used as a reason to
                                        > deprecate Content-Type, any number of RFC 3986 violations -- we're
                                        > clearly off into uncharted territory with little or no resemblance to
                                        > REST, and I've just scratched the surface. What else to make of this
                                        > move to just not mention "resource" and redefine URIs to identify
                                        > either documents or services? How is it possible to be more anti-REST?
                                        >
                                        >>
                                        >> Is there anything missing that would make it feasible and if so why
                                        >> is it missing? e.g. why did the efforts to introduce PUT and DELETE
                                        >> to <form> fail?
                                        >>
                                        >
                                        > What's missing is browser-vendor knowledge of architecture, or any HTTP/
                                        > URI interoperability issues not involving browsers. I won't speculate
                                        > as to why, it's not as if Roy didn't used to waste his breath explaining
                                        > to these people the finer points of why ad-hoc changes to WebArch are
                                        > short-sighted. Sufficient explanation to me of why no PUT, DELETE,
                                        > Xforms, list goes on -- not to mention feature removal...
                                        >
                                        > Clearly, the future of REST no longer lies with the browser. My status
                                        > nowadays is "on sabbatical" to recover my health, after recently "re-
                                        > homing" the last of my clients -- that one since 1994 which is how long
                                        > I've been developing Web sites for consumption in browsers. I have a 9-
                                        > week-old Alaskan Malamute to help me drop at least a couple stone before
                                        > I return, may take a few years.
                                        >
                                        > I'll continue to participate here, but when I return to Web development
                                        > it certainly looks like I'll be forsaking the browser for the native
                                        > app, where I can continue to bring my clients positive returns on their
                                        > online investments by leveraging REST to deal with the realities of the
                                        > netowrk currently being denied by the browser vendors.
                                        >
                                        > Should be interesting to watch, but the "new direction" has caused me
                                        > to pull my horse from the race; I no longer have any vested interest
                                        > nor do I care about the future of browsers. Only a sense that we'll be
                                        > cleaning up the mess for a long time to come -- corporate production
                                        > cycles, marketing imperatives, and bottom lines are no way to guide
                                        > the Web's architectural development, and this era can't end well.
                                        >
                                      • Glenn Block
                                        So no one has any thoughts on content-location with regards to reducing the need for a redirect?
                                        Message 19 of 20 , Jun 21, 2013
                                        View Source
                                        • 0 Attachment
                                          So no one has any thoughts on content-location with regards to reducing the need for a redirect?


                                          On Sat, Jun 8, 2013 at 7:35 AM, Mike Kelly <mikekelly321@...> wrote:
                                           

                                          On Sat, Jun 8, 2013 at 1:07 PM, Eric J. Bowman <eric@...> wrote:
                                          > Mike Kelly wrote:
                                          >>
                                          >> Even if that is a hard slog, it's probably the most likely way of
                                          >> getting the outcome you want.
                                          >>
                                          >
                                          > Like interoperability with things that aren't browsers, or which follow
                                          > RFC 3986? Highly doubtful.

                                          Ok, I disagree. Afaik, there isn't a more feasible course of action,
                                          and it sounds as if you are not going to invest any time on an
                                          alternative in the foreseeable future.

                                          I do share some of your concern though, so it would be intriguing to
                                          hear some specifics on what those alternatives might (or already do)
                                          look like... mamund? :)


                                          On Sat, Jun 8, 2013 at 2:02 PM, Eric J. Bowman <eric@...> wrote:
                                          > Mike Kelly wrote:
                                          >>
                                          >> What do you mean by 'undefined'? Running code has definitive
                                          >> behaviour: http://caniuse.com/
                                          >>
                                          >
                                          > REST is a defined architectural style. The link you've posted is all
                                          > about where a set of moving-goalpost features overlap at a moment in
                                          > time, which is hardly the same thing. While system behavior may be
                                          > definable, it's a by-product of the design process, as opposed to goals
                                          > used to guide the design process. What I mean by defined architecture
                                          > would be some sort of Taylor-school definition of just what's trying to
                                          > be accomplished, like REST was the model for the move to HTTP 1.1.
                                          >
                                          >>
                                          >> What is it, specifically, that you feel may be about to render
                                          >> browsers infeasible as the basis for a RESTful system?
                                          >>
                                          >
                                          > Silent error correction, content sniffing being used as a reason to
                                          > deprecate Content-Type, any number of RFC 3986 violations -- we're
                                          > clearly off into uncharted territory with little or no resemblance to
                                          > REST, and I've just scratched the surface. What else to make of this
                                          > move to just not mention "resource" and redefine URIs to identify
                                          > either documents or services? How is it possible to be more anti-REST?
                                          >
                                          >>
                                          >> Is there anything missing that would make it feasible and if so why
                                          >> is it missing? e.g. why did the efforts to introduce PUT and DELETE
                                          >> to <form> fail?
                                          >>
                                          >
                                          > What's missing is browser-vendor knowledge of architecture, or any HTTP/
                                          > URI interoperability issues not involving browsers. I won't speculate
                                          > as to why, it's not as if Roy didn't used to waste his breath explaining
                                          > to these people the finer points of why ad-hoc changes to WebArch are
                                          > short-sighted. Sufficient explanation to me of why no PUT, DELETE,
                                          > Xforms, list goes on -- not to mention feature removal...
                                          >
                                          > Clearly, the future of REST no longer lies with the browser. My status
                                          > nowadays is "on sabbatical" to recover my health, after recently "re-
                                          > homing" the last of my clients -- that one since 1994 which is how long
                                          > I've been developing Web sites for consumption in browsers. I have a 9-
                                          > week-old Alaskan Malamute to help me drop at least a couple stone before
                                          > I return, may take a few years.
                                          >
                                          > I'll continue to participate here, but when I return to Web development
                                          > it certainly looks like I'll be forsaking the browser for the native
                                          > app, where I can continue to bring my clients positive returns on their
                                          > online investments by leveraging REST to deal with the realities of the
                                          > netowrk currently being denied by the browser vendors.
                                          >
                                          > Should be interesting to watch, but the "new direction" has caused me
                                          > to pull my horse from the race; I no longer have any vested interest
                                          > nor do I care about the future of browsers. Only a sense that we'll be
                                          > cleaning up the mess for a long time to come -- corporate production
                                          > cycles, marketing imperatives, and bottom lines are no way to guide
                                          > the Web's architectural development, and this era can't end well.
                                          >


                                        • Nicholas Shanks
                                          ... I had previously suggested the very same, but apparently doing this raises security issues with intermediary caches. e.g. malicious page A sends response
                                          Message 20 of 20 , Jun 24, 2013
                                          View Source
                                          • 0 Attachment
                                            On 22 June 2013 03:16, Glenn Block <glenn.block@...> wrote:

                                            > So no one has any thoughts on content-location with regards to reducing the need for a redirect?

                                            I had previously suggested the very same, but apparently doing this
                                            raises security issues with intermediary caches. e.g. malicious page A
                                            sends response back claiming to be a representation of page B,
                                            intermediate layer caches this, and returns that response for future
                                            requests to B. There needs to be a way to declare that B trusts A to
                                            provide representations for itself, and for intermediaries to verify
                                            this before caching the response. Apparently being on the same domain
                                            is not sufficient for the HTTP folks.

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