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

19475Re: [rest-discuss] conneg considered harmful

Expand Messages
  • Glenn Block
    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.

    • Show all 20 messages in this topic