Re: conneg considered harmful

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 <[email protected]> wrote:

> **
>
>
> On Sat, Jun 8, 2013 at 1:07 PM, Eric J. Bowman <[email protected]>
> 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 <[email protected]>
> 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.
> >
>
>  
>