1Catalyst::TraitFor::ReqUuseesrt:C:oRnCEtaSrtTia:bl:uyFtsoetrd:B:rPToerwraslietrDFsoo(cr3u:)m:eRnetqauteisotn::REST::ForBrowsers(3)
2
3
4
6 Catalyst::TraitFor::Request::REST::ForBrowsers - A request trait for
7 REST and browsers
8
10 package MyApp;
11 use Moose;
12 use namespace::autoclean;
13
14 use Catalyst;
15 use CatalystX::RoleApplicator;
16
17 extends 'Catalyst';
18
19 __PACKAGE__->apply_request_class_roles(qw[
20 Catalyst::TraitFor::Request::REST::ForBrowsers
21 ]);
22
24 Writing REST-y apps is a good thing, but if you're also trying to
25 support web browsers, you're probably going to need some hackish
26 workarounds. This module provides those workarounds for you.
27
28 Specifically, it lets you do two things. First, it lets you "tunnel"
29 PUT and DELETE requests across a POST, since most browsers do not
30 support PUT or DELETE actions (as of early 2009, at least).
31
32 Second, it provides a heuristic to check if the client is a web
33 browser, regardless of what content types it claims to accept. The
34 reason for this is that while a browser might claim to accept the
35 "application/xml" content type, it's really not going to do anything
36 useful with it, and you're best off giving it HTML.
37
39 This class provides the following methods:
40
41 $request->method
42 This method works just like "Catalyst::Request->method()" except it
43 allows for tunneling of PUT and DELETE requests via a POST.
44
45 Specifically, you can provide a form element named "x-tunneled-method"
46 which can override the request method for a POST. This only works for a
47 POST, not a GET.
48
49 You can also use a header named "x-http-method-override" instead
50 (Google uses this header for its APIs).
51
52 $request->looks_like_browser
53 This attribute provides a heuristic to determine whether or not the
54 request appears to come from a browser. You can use this however you
55 want. I usually use it to determine whether or not to give the client a
56 full HTML page or some sort of serialized data.
57
58 This is a heuristic, and like any heuristic, it is probably wrong
59 sometimes. Here is how it works:
60
61 • If the request includes a header "X-Request-With" set to either
62 "HTTP.Request" or "XMLHttpRequest", this returns false. The
63 assumption is that if you're doing XHR, you don't want the request
64 treated as if it comes from a browser.
65
66 • If the client makes a GET request with a query string parameter
67 "content-type", and that type is not an HTML type, it is not a
68 browser.
69
70 • If the client provides an Accept header which includes "*/*" as an
71 accepted content type, the client is a browser. Specifically, it is
72 IE7, which submits an Accept header of "*/*". IE7's Accept header
73 does not include any html types like "text/html".
74
75 • If the client provides an Accept header and accepts either
76 "text/html" or "application/xhtml+xml" it is a browser.
77
78 • If it provides an Accept header of any sort that doesn't match one
79 of the above criteria, it is not a browser.
80
81 • The default is that the client is a browser.
82
83 This all works well for my apps, but read it carefully to make sure it
84 meets your expectations before using it.
85
87 Dave Rolsky, "<autarch@urth.org>"
88
90 Please report any bugs or feature requests to
91 "bug-catalyst-action-rest@rt.cpan.org", or through the web interface at
92 <http://rt.cpan.org>. We will be notified, and then you'll
93 automatically be notified of progress on your bug as I make changes.
94
96 Copyright 2008-2010 Dave Rolsky, All Rights Reserved.
97
98 This program is free software; you can redistribute it and/or modify it
99 under the same terms as Perl itself.
100
101
102
103perl v5.34.0 Catal2y0s2t2:-:0T1r-a2i0tFor::Request::REST::ForBrowsers(3)