Re: [rest-discuss] 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 <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 followOk, I disagree. Afaik, there isn't a more feasible course of action,
> RFC 3986? Highly doubtful.
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.
- 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.