I proposed a solution, the package Resty::Controller::API; example I sent earlier. Trying to write your controller using Catalyst::Action::Deserialize is a mistake, as it's not what Deserialize does. from http://search.cpan.org/~bobtfish/Catalyst-Action-REST-0.87/lib/Catalyst/Action/Deserialize.pm
"This action will deserialize HTTP POST, PUT, and OPTIONS requests. It assumes that the body of the HTTP Request is a serialized object. The serializer is selected by introspecting the requests content-type header." You want to deserialize a GET request. GET requests have no body. GET requests generated by <script src> tags request content-type "*/*". So the correct way to code this would be handle it as what it is, a GET request with a parameter that's JSON encoded, for which you can use something like the example I provided earlier or just a regular controller with a base that decodes the encoded parameter and does what you want. -Sam On Tue, Nov 23, 2010 at 11:56 AM, Ronald J Kimball <[email protected]> wrote: > On Mon, Nov 22, 2010 at 3:12 PM, Aristotle Pagaltzis <[email protected]> wrote: >> This is really, really, really bad. It’s roughly like modifying >> a file system to be allow file deletion as a side effect of >> opening a file. GET is supposed to be safe, that is, it should be >> free of side effects that the user cannot be held responsible >> for. It is very, very easy to get a browser to send GET requests >> incidentally, eg. by putting the link in a `<img src>` or >> a stylesheet `<link>` and getting a user to visit. Things like >> Google Web Accelerator and other automated user agents (like >> search engines of course) also generally assume that GET is safe. >> Much web infrastructure also assumes that GET requests are >> cacheable, so if there are any proxies between the app and the >> user, sending multiple pseudo-POST requests may not actually do >> anything. > > I completely understand the points you're making here. As I said, one > of the drawbacks of this solution is that it makes me feel really > dirty. > > For what it's worth, the REST methods that I want to expose in this > way are for posting responses to content. There won't be any deletes. > > >> The same-origin policy is not there by mistake, but to keep your >> users safe from malicious 3rd party sites they may visit. > > REST principles dictate that I use POST, not GET, for these requests. > The same-origin policy forces me to use JSONP, which can only make GET > requests, not POST. What's the solution? > > > Ronald > > _______________________________________________ > List: [email protected] > Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst > Searchable archive: http://www.mail-archive.com/[email protected]/ > Dev site: http://dev.catalyst.perl.org/ > _______________________________________________ List: [email protected] Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/[email protected]/ Dev site: http://dev.catalyst.perl.org/
