rest/rails
Rails on REST Wish List
Draft 1, 11/3/2005
REST-style URIs
That is, make the default URL style: http://host/base/table/id/style as in: http://localhost:3000/mydemo/person/113
for the default view, with an optional "/edit" on the end for, e.g., forms vs. a list.
This is subtly different than the current "table/action/id" which scaffolding generates. The central concept in REST is that every object (noun) should have a unique URI, and having an action inlined screws that up.
POST vs. GET
Right now, as far as I can tell, Rails doesn't differentiate results from a POST vs. results from a GET. Those are semantically different in REST, so I'd like [to know] a way to handle that cleanly.
XOXO-style templates
I'd like the default rhtml templates to be XOXO-compatible (e.g., dt/dd rather than <p>/<br>).
Columns as class names
In addition to 'human_readable' column names, I'd like there to be a parameter for the equivalent 'css-friendly' representation of those columns -- and for the default templates to include that.
Complete, functioning, customizable web application
I want to be able to do something like:
$ script/generate rex modelA modelB
And get a full-blown web application which includes:
- the front page, including navigation links to various model objects.
- search boxes
- entry forms
- AHAH (ajax) responses
- both list- and table- oriented model representations
The ideal is that I could use a combination of CSS and AHAH to generate the desired look, feel, and behavior of my website without actually having to touch existing HTML. As a bonus, I also want it complete enough that I can write a REST-spider to easily discover all the valid URIs and queries. Hey, a guy can dream...
XOXO instead of YAML for configuration
Okay, this last one is really nit-picky, and a little odd, but it would (IMHO) be more consistent. Right now, the config is the only non-HTML, non-Ruby file, and I at least had never seen YAML before so it looked out of place. Granted, using XHTML for config files is a little freaky at first, but when you think about it, its no worse than using custom XML tags (and way more interoperable). I'll even write the Ruby serializer myself if I have to...