User:Dan Kubb

2006-04-28T22:53:33Z

Dan Kubb:

Dan Kubb [http://autopilotmarketing.com/~dan.kubb/vcard vCard]

irc

2006-04-28T22:50:53Z

Dan Kubb: /* People on irc */

__NOTOC__
= Microformats IRC =

We have an IRC channel, [irc://irc.freenode.net#microformats #microformats on the freenode network].

There's typically someone there at any point during the day, though there isn't always active discussion. Sometimes, though this is the best place to discuss issues that need lots of back and forth discussion.

== People on irc ==
A list of IRC regulars and their normal timezones. (winter/summer)

* [[User:Amette|amette]] (+1000)
* [[User:B.K._DeLong|bkdelong]] (-0500/-0400)
* [[User:Ben Ward|BenWard]] (+0000)
* [[User:BenjaminCarlyle|BenjaminCarlyle]] (+1000)
* [[User:Boneill|boneill]] (+0000)
* [[User:Brian|briansuda]] (-0600/-0500)
* [[User:ColinDDevroe|cdevroe]] (-0500/-0600)
* [[User:Cgriego|cgriego]] (-0600/-0500)
* [[User:ChrisCasciano|pnhChris]] (-0500/-0400)
* [[User:ChrisMessina|factoryjoe]] (-0800/-0700)
* [[User:ChristopherStJohn|cks]] (-0600/-0500)
* [[User:DanC|DanC]] (-0600/-0500)
** office hours: Wednesday afternoons, America/Chicago time
* [[User:Dave Cardwell|davecardwell]] (+0000)
* [[User:DimitriGlazkov|dglazkov]] (-0600/-0500)
* [[User:EdwardOConnor|hober]] (-0800/-0700)
* [[User:Enric|enric]] (-0800/-0700)
* [[User:Evan|evanpro]] (-0500)
* [[User:Fil|Fil]] (+0200)
* [[User:Hlb|hlb]] (+0800-0700)
* [[User:IanHickson|Hixie]] (-0800/-0700)
* [[User:Izo|IZO]]
* [[User:JoeGregorio|jcgregorio]]
* [[User:Jonathan_Arkell|jonnay]] (-0700/0600)
* [[User:Keri Henare|kerihenare]] (+1200)
* [http://epeus.blogspot.com/ KevinMarks] (-0800/-0700)
* [[User:Mark Mansour|Mark Mansour]] (+1100)
* [[User:neuro|neuro`]]
* [[User:RobertBachmann|RobertBachmann]] (+0100/+0200)
** Office hours: Wednesday, 20:30-21:30 UTC
* [[User:RyanKing|kingryan]] (-0800/-0700)
** [http://theryanking.com/blog/archives/2006/04/19/office-hours/ Office hours]: Wednesday, 21:00 UTC
* [[User:Dana Benson|Snowden]] (-0800/-0700)
* [[User:Steve Ganz|SteveGanz]] (-0800/-0700)
* [[User:Tantek|Tantek]] (-0800/-0700)
* [[User:Dan Kubb|dkubb]] (-0800/-0700)

=== bots ===

* [[mfbot]]
* [[mflogbot]]
* [http://joi.ito.com/joiwiki/JiBot jibot]

== Logs ==

Available here: http://rbach.priv.at/Microformats-IRC/

== IRC meetups ==

The idea of having IRC meetups (that is, a set time for meeting on IRC) has been suggested by [[User:RyanKing|Ryan King]], as it appears to work well for the WordPress community and may help us from time-to-time. As of yet, there are no plans to have meetups, though.

rest/rails

2006-04-21T21:38:48Z

Dan Kubb: /* RESTful Rails */

= Plug-ins =

Currently there are two different approaches to doing REST on Rails. The first emphasizes consistency with existing Rails idioms, while the second attempts to streamline implementation of RESTful best practices. The two hope to eventually share much of the code, but will ultimately still employ different controller architectures due to their different goals.

== Simply RESTful ==
http://dev.rubyonrails.org/browser/plugins/simply_restful
* Inspired by: http://pezra.barelyenough.org/blog/2006/03/another-rest-controller-for-rails/

The primary goal of ''Simply RESTful'' is to enable developers who follow common Rails idioms to get RESTful behavior for "free". One major aspect of that is changing the way URLs are generate and used, according to the following conventions :

{| class="wikitable" style="text-align:center" border="1" cellpadding="5" align="center"
! HTTP verb !! URL structure !!Rails method
|-
| GET || /items || index
|-
| GET || /items/new || new
|-
| POST || /items || create
|-
| GET || /items/1 || show
|-
| DELETE || /items/1 || destroy
|-
| POST || /items/1?_method=DELETE || destroy
|-
| GET || /items/1;edit || edit
|-
| POST || /items/1 || update
|-
| POST || /items/1;complete || complete
|-
|}

== RESTful Rails ==
http://rubyforge.org/projects/restful-rails/

Status of Desired Features:
* + being full support
* ~ being sort-of
* - being non-existent

<table>
<tr>
<th>Status</th>
<th>Name</th>
<th>Description</th>
</tr>
<tr>
<td>+</td>
<td>Cool URIs</td>
<td>Standardized URI structure</td>
</tr>
<tr>
<td>+</td>
<td>Method Dispatching</td>
<td>Executing different code based on the URI and method</td>
</tr>
<tr>
<td>~</td>
<td>Status Codes</td>
<td>Returning the "best" HTTP status codes for methods</td>
</tr>
<tr>
<td>-</td>
<td>Content Negotiation</td>
<td>Returning the "best" content based on the client Accept* headers</td>
</tr>
<tr>
<td>+</td>
<td>Conditional Request</td>
<td>Handle the If-* headers properly and return [http://rfc.net/rfc2616.html#s10.3.5 304 Not Modified] or [http://rfc.net/rfc2616.html#s10.4.13 412 Precondition Failed] as appropriate</td>
</tr>
<tr>
<td>+</td>
<td>Caching Headers</td>
<td>Easier ways to set the Expires and Cache-Control headers</td>
</tr>
<tr>
<td>-</td>
<td>Warnings Headers</td>
<td>Possibly use them to communicate error messages in a content agnostic manner</td>
</tr>
<tr>
<td>+</td>
<td>OPTIONS support</td>
<td>Use reflection to see what methods a URI allows so it can be reported with [http://rfc.net/rfc2616.html#s9.2 OPTIONS]</td>
</tr>
<tr>
<td>~</td>
<td>HTTP Authentication</td>
<td>Provide an easy way to do normal [http://rfc.net/rfc2617.html Basic and Digest] (and maybe WSSE) authentication</td>
</tr>
</table>

= Wish List =

[Portions may be obsoleted due to above plug-ins solving these problems differently]

While nominally focused on specific feature requests to add to Rails, in fact many of these recommendations are also relevant for other frameowrks, and even general "REX".

== 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...

== OPTIONS Handling ==

The controller should be able to handle OPTIONS requests
and know what specific methods it can handle for a given
URI.

== Output Content Negotiation ==

It would be nice to be able to have the view look at
the Accept headers and choose the best template to
output.

For example, imagine you had the following files:

* index.rhtml
* index.rxml
* index.rtxt

If the browser sent the Accept as text/html then the
index.rhtml would be used. For text/plain the
index.rtxt would be used, and so on.

If there was a way for a view handler to "register"
itself and say what mime types it knows how to handle,
then the optimal handler could be chosen at runtime.
The handlers could do anything they want in order
to output the response body, including using libraries
like GD.

== Input Content Negotiation ==
When a request has a body, it needs to be parsed and
stored into the request parameters. Rails handles
normal web forms and multi-part form input.. but
it would be nice to be able to write custom handlers
that knows how to parse requests for specific
mime-types and set the appropriate request parameters
inside rails.

This would allow you to POST a web form or a yaml
string and have the values funneled into the same
parameters -- your controller wouldn't care where
the data is come from. I realize yaml is supported
by rails natively, but it should be possible to
register handlers for any other mime types.

Perl's Catalyst MVC is starting to do this with
their HTTP::Body module.. they made it so you can
write custom modules to parse any mime-types and
set the request parameters.

== HEAD responses ==

Responses to HEAD requests should be identical to
GET requests, minus the body. Rails should omit sending
the body for HEAD requests, but still send all the appropriate
headers. Its especially important that the Content-Length be
the same for HEAD and GET responses.

== Conditional GET requests ==

When writing mod_perl handlers I was able to do something
equivalent to:

def get_index
# do some work to set up @resource
set_etag @resource.digest_hash
set_last_modified @resource.updated_at
return not_modified if conditional_get?
render
end

This resulted in a snappier response from some apps since it
didn't require a full transfer if it was not modified since
my last request.

== AJAX apps to use HTTP more fully ==

Most Rails AJAX apps use only GET and POST, but they should be encouraged to use the full set of HTTP verbs in examples.

Encouragement of Conditional GET in AJAX apps would be a bonus as well.

= Proposal =
As proposed on April 1st by Charlie Savage, in response to Dan Kubb

== Syntax ==
The currently proposed syntax is:
<pre> resource :collection do |r|
    r.post do
    end
end</pre>
Where 'r' is an instance of a Resource class. At first I preferred a simpler syntax, like this:
<pre> resource :collection do
    method.post do
    end
end</pre>
Where method represents the HTTP verb (GET, POST, PUT)? Or maybe even:
<pre> resource :collection do
    request.post? do
    end
end</pre>
However, do you have to have an instance of the resource class to achieve the 4 points you brought up (more details in original email):
# Handling OPTIONS requests.
# Returning 405 when appropriate
# Return 501 when appropriate
# Checking If-* request

These all would be good features to have. If they require having a resource class passed as "r" then I can agree to this approach.

== Templates ==
You mentioned that you'd expect these responses for different methods:
;GET    - 200 OK        : Response Body
;POST   - 303 See Other : No Response Body, Location header to newly created resource
;PUT    - 303 See Other : No Response Body, Location header to resource
;DELETE - 303 See Other : No Response Body, Location header to collection resource
Using regular HTML forms I'd agree. However, this breaks down when using XmlHttpRequest. For example, if I do a post and it fails and I want to return an error message. Doing a redirect is a bit silly since the URL in the browser address bar isn't going to change anyway - its easier to just return the result from the POST. Same is true for a PUT, whether an update is successful or not.
Thus, I think we must provide a system where you can provide a response body regardless of the method. One approach is Peter's proposal of just using a standardized directory structure:
<pre> view
    my_controller
        resource1
            get
            put
       resource2
           post
          delete</pre>
I like this concept. However, maybe it would be confusing since Rails uses directories for nested classes (MyNamespace::MySubNamespace::MyController). Thus, we could go use the name mangling I currently do now, i.e., get_resource1, or resource1_get (which I like better because it groups the templates for a resource together a bit more clearly).

== Editors ==
We seem to be in complete agreement. I.E:
;/book/1        :   Viewable representation of book #1 retrieved by GET
;/book/1/editor :   Editable representation of book #1, will PUT to /book/1
;/book/creator :   Form to create a new book, will POST to /book

== Top Level Resources ==
Here is something Peter and I disagree about. Do you prefer this style:
=== Option #1 ===
<pre> def MyController
   resource :collection do |r|
      ...
   end
   resource :member do |r|
      ...
   end
   resource :editor do |r|
      ...
   end
end</pre>

=== Option #2 ===
Or this:
<pre> def MyController
   r.get
      ...
   end
   r.post
      ...
   end
   resource :member do |r|
      ...
   end
   resource :editor do |r|
      ...
   end
end</pre>
The difference being in the first case you insist every resource must be defined via "resource" while in the second you say that the controller is the top level resource. When I first did my RestController I went with option #1 because it seemed more elegant. However, I quickly changed my mind when actually writing code because it turned out to be annoying having to add the extra syntax. This was particularly true for controllers that are just single resources. For example, say you have geocoding functionality so you have a GeocoderController. It does just one thing, GETs geocoding results so there is no concept of collection/member. Thus I favor option #2 as a syntax shortcut.

== Caching ==
Sounds like we've agreed that caching is important, but is not part of the Rest Controller. Thus, you'll split that off the caching functionality into another plugin that can work with a Rest Controller.

== Implementation ==
I see that your implementation is significantly different than mine. I map :resource to a Ruby module, which gets included in a controller. In contrast, you map :resource to a Ruby method. Within that method you create an instance of a Ruby class called Resource and then execute the provided block in its context.

This disadvantage of my approach is that there is method renaming that goes on under the scenes, which you have to know about in order to get filters to work correctly. The disadvantage I see to your implementation is that all the methods for a resource get mapped under a single Ruby method. It seems that would make it hard to apply filters to specific methods. I.E., how could I apply a filter to a GET method of the resource Member but not to the POST? It would be great if we could use the existing filter syntax without change, but I'm guessing that might not be reasonable because now we are dealing with Resources and Methods as opposed to Actions. Anyway, this is something I think is important to solve.

Also, how does your Rest controller interact with the base ActionController? I'm not seeing it being include anywhere...could you point me to the appropriate code.

== Examples (TBD) ==

Last, it would be good to have an example controller for people to play with. Something simple, like a ProductController or maybe copying one of the examples from the Agile Web Development book.

* Dan Kubb's XML.com article: http://www.xml.com/lpt/a/2006/04/19/rest-on-rails.html

Microformats Wiki - User contributions [en]

User:Dan Kubb

irc

rest/rails