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

Re: [rest-discuss] conneg considered harmful

Expand Messages
  • Eric J. Bowman
    ... Like interoperability with things that aren t browsers, or which follow RFC 3986? Highly doubtful. -Eric
    Message 1 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 2 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 3 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 4 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 5 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.