[Catalyst] Re: How are you handling multiformat URL

John Napiorkowski jjn1056 at yahoo.com
Wed Nov 29 20:50:59 GMT 2006


--- "A. Pagaltzis" <pagaltzis at gmx.de> wrote:

> * John Napiorkowski <jjn1056 at yahoo.com> [2006-11-29
> 00:05]:
> > I often find that the resource of a given URI can
> have
> > alternative formats.  For example, I might have a
> table of
> > information on an html webpage and I want to offer
> two
> > alternative representations, a comma separated
> version and an
> > ATOM feed.
> 
> It’s not ATOM, any more than Perl is PERL. :-)
> It’s just Atom.
> The name doesn’t stand for anything.
> 
> > So, what are you all doing to handle this?  Has
> the 'cool urls
> > don't have file extensions' school of though
> fallen out of
> > favor?  Has someone found a better way, or a
> compelling reason
> > to choose one over the other?
> 
> HTTP has had an answer for this for a long time,
> although it
> hasn’t seen much use. (Just like a lot of HTTP in
> general…) It’s
> called Content Negotiation and revolves around the
> Accept header.
> 
> HTTP in general has a three-pronged architecture:
> URIs, resources
> and representations. URIs identify resources, but
> each resource
> can have multiple representations. Clients can use
> the Accept
> header on a request to supply a list of MIME types
> they
> understand, complete with a preference ranking. The
> server can
> use this to decide which representation of the
> resource it will
> serve.
> 
> In practice, conneg (content negotiation) suffers
> from both
> conceptual problems and neglect. The conceptual
> problem is that
> that he resource/representation duality is often
> fuzzy, and
> conneg makes it harder to use the main cornerstone
> of web
> architecture, ie. identify specific things by URI,
> which is
> a powerful concept.
> 
> My current thinking on how to handle things is based
> on the fact
> that the form of response to a request with conneg
> is entirely at
> the server’s discretion. So I think this makes the
> most sense:
> 
> • The resource is identified by
> <http://example.org/foo>.
> 
> • Requests with (explicit or implicit) `Accept: *`
> directly
>   return the default representation in the body of a
> 200 OK
>   response.
> 
> • Requests with a more restrictive Accept header
> which the server
>   deems it can serve are answered with a 302
> redirect.
> 
> • Such redirects go to
> <http://example.org/foo.ext>.
> 
> • If a request to <http://example.org/foo.ext> has
> an Accept
>   header that precludes the media type of that
> particular
>   representation, the server responds 406 Not
> Acceptable.
> 
> An open question I have is whether requests to
> <http://example.org/foo.ext> with `Accept: *` should
> actually
> serve the resource or redirect back to
> <http://example.org/foo>
> – which would mean that unless you insist on a GIF
> image when you
> ask for <http://example.org/foo.gif>, you might
> actually get
> a PNG image from <http://example.org/foo>. Yeah, it
> sounds crazy,
> but the issue at hand is “canonical URIs.” Eg. I
> don’t want
> a search engine spider to index my content thrice,
> just because
> I offer it as all of text/plain, text/html and
> application/xhtml+xml.
> 
> Mind you, this is not at all practice-proofed.
> It’s just my
> current hypothesis as to the probably best approach
> to handle
> this.
> 
> I decided for the /foo.ext rather than the
> /foo?format=ext
> approach because there’s no difference in
> information conveyed
> between the two.

I think for me one of the issues with using the
"name.ext" route is finding the best way to support
this in catalyst.  There are a couple of options.  You
can create a Regex type action to capture all possible
extensions and then let the controller decide what to
do, or you can explicitly name each extension in an
action Path type (which I think is the only solution
if you are using Chained methods with PathPart).

Or there is the Flavour plugin, which modifies the
action to remove the extension and store it in
accessor.

I've been using the Flavour plugin with good success
to handle this.  How about the rest of you?

--john


> 
> Regards,
> -- 
> Aristotle Pagaltzis // <http://plasmasturm.org/>
> 
> _______________________________________________
> List: Catalyst at lists.rawmode.org
> Listinfo:
> http://lists.rawmode.org/mailman/listinfo/catalyst
> Searchable archive:
>
http://www.mail-archive.com/catalyst@lists.rawmode.org/
> Dev site: http://dev.catalyst.perl.org/
> 



 
____________________________________________________________________________________
Do you Yahoo!?
Everyone is raving about the all-new Yahoo! Mail beta.
http://new.mail.yahoo.com



More information about the Catalyst mailing list