Accept Handling for Representations
Eero Saynatkari
In preparation to moving forward with the new DSL, the
Accept/file extension matching has been changed in HEAD.
This may be necessary to be changed in the future, but
I have a slim hope of being able to support both dumb
web browsers and rich clients in the same callpath, thus
expressed:
The basic idea is that a file extension, if present, will
override anything in Accept with its own MIME type. The
absence of an extension is indicated with Mime::Undefined,
allowing e.g. matching /foo/bar to the text/html repr.
Code is typically better than some number of words, so
please see the Accept test file:
http://github.com/waves/edge/blob/fc0b801e5c61cbf0efcba08d0604920d75e45a2f/test/match/accept.rb
The scheme is slightly more cumbersome than the current,
but richer. It will be abstracted away under the new DSL.
Regards,
Eero <rue>
--
Magic is insufficiently advanced technology.
ab5tract
On Apr 15, 5:25 pm, Eero Saynatkari <registrati...@kittensoft.org>
wrote:
>
> In preparation to moving forward with the new DSL, the
> Accept/file extension matching has been changed in HEAD.
> This may be necessary to be changed in the future, but
> I have a slim hope of being able to support both dumb
> web browsers and rich clients in the same callpath, thus
> expressed:
>
> The basic idea is that a file extension, if present, will
> override anything in Accept with its own MIME type. The
> absence of an extension is indicated with Mime::Undefined,
> allowing e.g. matching /foo/bar to the text/html repr.
>
> Code is typically better than some number of words, so
> please see the Accept test file:
>
Eero Saynatkari
>
> Hey,
>
> In preparation to moving forward with the new DSL, the
> Accept/file extension matching has been changed in HEAD.
> This may be necessary to be changed in the future, but
> I have a slim hope of being able to support both dumb
> web browsers and rich clients in the same callpath, thus
> expressed:
I re-enabled the Ext matcher as a backup, although in my
view the Accept matcher should be the primary one used in
all contexts, and it can still be used with extensions as
well, its semantics are unchanged. We discussed possibly
moving the combined matching to Requested (or something),
but I have not addressed that here.
Otherwise, I added a bunch of matcher specs and fairly
significantly altered the matcher processing. Please
chime up if there is a problem.
Dan Yoder
Option 1. Pragmatic expansion of Accept to include extensions. This is the idea Eero has described in prior posts in this thread. The advantage of this is that it reflects common practice in the developer community, not slavish devotion to a possibly flawed standard.
Option 2. Adding a new matcher (:requested) that incorporates extensions per Eero :accept implementation. This has the advantage of preserving the standards-based definition of "Accept", while still allowing developers to use the de facto standard approach.
My concern with Option 1 is that the de facto practice is not only at odds with the standard, but violates REST constraints. Namely, that the URI should identify a resource, not a representation. Although common practice, it is not so common that there is significant existing client or proxy code out there that depends on it. By promoting this approach, I think we are helping to undermine the eventual move towards useful adoption of REST-based architectures.
There seems to be a lot of skepticism about the value of such architectures, at least in so far that they go beyond the basic use of the HTTP verbs. That is understandable, but in principal, Waves has always tried not to have strong opinions. Whenever possible the idea is to support multiple approaches. This is why, for example, we have an MVC Foundation. I think supporting both proper :accept and an extended variant via :requested is a way to give developers a choice. If they want to use the standard as written, they can use :accept. If they want to incorporate extensions, they can use :requested. Furthermore, it is entirely possible (albeit potentially confusing) that the MVC Foundation might use :accept to include extensions, while the REST Foundation does not.
One last point: I don't think the REST Foundation should view Web browsers as the primary client. There are now thousands of APIs out there, not to mention RSS and Atom feeds by the tens of thousands. Even Web apps are increasingly Ajax-based, which means increasingly they are circumventing the browser. Even more interesting, the emergence of the mobile Web means there are more and more hybrid "thin-clients" out there. The browser remains a very important client platform, don't get me wrong. But I think it is slowly becoming one of many, instead of the 80/20 case.
I bring this last point up because, for conventional Web apps, there is little point to the :requested matcher. Browsers rarely do the right thing with the Accept header and never, on their own, ask for "application/json" (as an example), let alone custom media types. But not only is it possible to correct this behavior using XMLHttpRequest, but I think more and more we will see non-browser clients, where it will not be such a big deal to specify the correct Accept header (or the language or encoding or if-modified, none of which have de facto URI conventions).
Thoughts?
Regards,
Dan
Eero Saynatkari
> Okay, I'm a bit late to chime in here. I believe KK has updated edge with a
> slight difference, which reflects my own opinion about this. Eero and I have
> gone back and forth on this issue. There seem to be two resolute
> perspectives (Eero, please chime in if I misrepresent the one you've been
> advocating).
>
> idea Eero has described in prior posts in this thread. The advantage of this
> is that it reflects common practice in the developer community, not slavish
> devotion to a possibly flawed standard.
>
> per Eero :accept implementation. This has the advantage of preserving the
> standards-based definition of "Accept", while still allowing developers to
> use the de facto standard approach.
>
> My concern with Option 1 is that the de facto practice is not only at odds
> with the standard, but violates REST constraints. Namely, that the URI
> should identify a resource, not a representation. Although common practice,
> it is not so common that there is significant existing client or proxy code
> out there that depends on it. By promoting this approach, I think we are
> helping to undermine the eventual move towards useful adoption of REST-based
> architectures.
(I use the convention of :matcher, Header as a shorthand.)
Before going any further, I should point out that the issue
is essentially moot: I have no qualms with the :requested
matcher (in particular because the REST DSL will never use
it explicitly, I hope.) I shall explain my reasoning for
originally just modifying :accept instead, though:
Notably, I think the main miscommunication was because we
viewed the :accept matcher slightly differently: it seemed
to me that Dan's view was that :accept should be exactly and
only the contents of the Accept header.
My view, oddly enough, had absolutely nothing to do with a
preceding practice. Aside from my continued belief that the
HTTP spec is broken on this part ("accept" is not a good
term to mean "request", which is what the HTTP logic really
means), my starting point was that doing thing strictly by
(the intention of) the spec is the only option. This means
that, conceptually, the type should be specified only by
Accept and consequently that is how we should determine the
type requested.
There is just the small matter of web browsers.
I disagree on the point of resource identifiers; aside from
the obvious part that they somehow identify a resource, it
is another poorly defined part of the REST architecture.
Because the HTTP spec says nothing about file extensions,
and because it is somewhat awkward to consider /foo/bar.txt
and /foo/bar.html to be different resources, and because it
is a fairly well-established convention *elsewhere* to use
extensions as type indicators, to me extensions would be
the natural __workaround__ for the inability of browsers to
actually set the Accepts correctly (although this may be
changing in HTML5.)
So this takes us to the argument Dan was sort of going at
the end, and which was the original problem I was solving.
I do not think we have a good solution, still, but here is
one proposal:
1. Using :requested means you do not care how the type is
resolved, just that all clients can indicate it and
that you get the information.
2. In your responses, the links can be either given with
info suitable to use in Accept, or simply appended the
appropriate extension to. (The latter generally only
being the case when you are returning a HTML variant.)
3. There is no need to change code when/if Accept becomes
dominant.
This probably fits most use cases. But is it the best way?
What do the alternatives (either for :requested generally
or for using file extensions in particular) look like?