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

Re: [rest-discuss] conneg considered harmful

Expand Messages
  • 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 1 of 20 , Jun 7, 2013
    • 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 2 of 20 , Jun 7, 2013
      • 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 3 of 20 , Jun 7, 2013
        • 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 4 of 20 , Jun 8, 2013
          • 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 5 of 20 , Jun 8, 2013
            • 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 6 of 20 , Jun 8, 2013
              • 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 7 of 20 , Jun 8, 2013
                • 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 8 of 20 , Jun 21, 2013
                  • 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 9 of 20 , Jun 24, 2013
                    • 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.