[uf-rest] RESTified Rails Controller (take 2)

[Dan Kubb]

Hi Peter,

> Do you think it would be possible to implement RestController
> as an extension to ActionController::Base for the etag stuff
> (as that is really applicable any request) and as a mixin for
> the http-method based routing and actions?

Actually that's exactly the direction I'm taking things. For the
first iteration I did the simplest thing that could work, which
was put everything in a single file, but for my latest version
I've split things up quite a bit.

This evening I'd planned on moving the methods that deal with
HTTP headers so they mix-in to ActionController::AbstractResponse
and ActionController::AbstractRequest. I'll also have a module
for handling conditional requests, something that can be used
even without the HTTP method based routing.

Once I get it working and tested I'll package it up as a plugin.

> Have you had any epiphanies about how to handle multiple
> representations/views of the same resource?

Nothing rock solid yet. I do know I'd like to try to keep the
controller code the same regardless of the representation. Any
view specific code would likely be placed in the template or in a
helper library. I do know I'll probably use a form of Content
Negotiation to choose the view, where the Accept* headers will be
used to decide what representation to return.

I made something like this once before for an in-house
mod_perl MVC system that worked pretty well. Basically I had
several types of views that registered themselves with the
controller. Each view knew what type of representation they could
output, the language, its mime type, and had a sort of 'score'
that ranked it higher or lower than the other representation in
terms of quality. (The score was totally subjective, like I'd
probably rate text/x-yaml higher than text/xml, simply because
the size is smaller for the same amount of information.)

Each of the views was completely independent in how it rendered
itself, it only had to know how to register itself with the
controller (at startup) and respond to a couple of methods that
describe its properties.

So when a request came in, I'd cycle through all the controller's
registered views, map the data into perl's HTTP::Negotiate library.
Using that I would narrow things down to a preferred view using the
client's Accept* headers. Basically, this allowed the client to
negotiate with the server what it preferred to receive, which was
rendered when I called the equivalent of render at the conclusion
of the controller action method.

All the negotiation was done before the controller's action was
even executed so if the client asked for representations that the
server couldn't output, a 406 Not Acceptable exception was
returned and no action was executed.

> How are you handling routing? Have you just modified the routes
> in the restifarian plugin to match your action names or have you
> come up with something different?

I'm just doing it sort of brute force for right now. I am using
the same naming conventions as the restifarian plugin though.

On your blog we talked about defining the routing inside each
controller, but I've not really run into any problems yet using
normal Rails route system so its lower on my priority list right
now...

-- 

Thanks,

Dan
__________________________________________________________________

Dan Kubb                  Email: dan.kubb at autopilotmarketing.com
Autopilot Marketing Inc.  Phone: 1 (604) 820-0212
                             Web: http://www.autopilotmarketing.com
__________________________________________________________________