Re: conneg considered harmful

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.
>