[uf-rest] Fwd: REST and Rails

[Charlie Savage]

>
> I still think I prefer the top-most syntax.  In fact, I think the third
> one could potentially introduce bugs because of the 4 steps that are
> performed.  I suppose you could get around that by explicitly testing
> the conditions, but its not really necessary, most people will forget,
> and should ALWAYS be performed before executing the per-method handler.
Agreed
>
> The response pattern I normally use for web services (including AJAX 
> clients) is the
> following:
>
>   GET    - 200 OK         - Response Body
>   POST   - 201 Created    - No Response Body, Location header to newly 
> created resource
>   PUT    - 204 No Content - No Response Body
>   DELETE - 204 No Content - No Response Body
>
> I'm very particular about what headers and response body I return for
> specific methods.  I suppose some people would execute a PUT, and then
> return the same response body as you'd get when issuing a GET in order
> to cut out a round-trip to the server.  To me that smells like a 
> premature
> optimization of sorts.   I'd prefer to keep the API simple and 
> consistent,
> and if I need to know the current state of the resource I'll perform a
> Conditional GET on the resource, not rely on a "PUTGET" to know the 
> state.
Well, the HTTP spec (section 9.6 PUT) says:

<<
If a new resource is created, the origin server MUST inform the user 
agent via the 201 (Created) response. If an existing resource is 
modified, either the 200 (OK) or 204 (No Content) response codes SHOULD 
be sent to indicate successful completion of the request. If the 
resource could not be created or modified with the Request-URI, an 
appropriate error response SHOULD be given that reflects the nature of 
the problem. The recipient of the entity MUST NOT ignore any Content-* 
(e.g. Content-Range) headers that it does not understand or implement 
and MUST return a 501 (Not Implemented) response in such cases.
 >>

My understanding is that its valid to return a response body from a PUT 
or a POST, so I don't think we should stop people from doing it if 
that's what they want to do.  In addition, when using XmlHttpRequest it 
can be quite handy to return an error message saying what went wrong in 
case of an HTTP error code (which is what I use it for) as opposed to 
having to go back to the server to GET it (which means you'd need to 
turn the error into a resource which seems like overkill).


> For example, if you had a ton of code that looked like this:
>
>   resource :collection do |r|
>     # ... get the models ...
>
>     r.post do
>       # ... do some work ...
>       render :template => 'collection_post'
>     end
>
>     r.put do
>       # ... do some work ...
>       render :template => 'collection_put'
>     end
>   end
>
> Then I'd say go with it.  But if you attempt to use the patterns I 
> outlined
> above, I don't think you'll see it too often.
>
> I've mentioned before, but I'm always cautious about breaking 
> fundamental Rails
> conventions for our own purposes, like the naming and location of 
> templates.
> There's so much already out in the wild that relies on those 
> conventions that
> to break one means that you suddenly have to re-implement other 
> functionality
> that rely on those conventions.  Maybe in this particular case it 
> won't be
> a big deal (I don't know), but we get alot for free with rails and I'd 
> like
> to keep as much as I can by sticking with conventions by default.
>
Agreed.  To me, one of those fundamental conventions is that Rails picks 
a template for you unless you override it.  I think we need to provide 
the same mechanism for a Rest Controller.

My approach was to map resource/methods to templates like this:

get_collection, post_collection, get_member, etc.

This did require changing the action name, which would be nice to avoid.

Does anyone have any thoughts on this or have a better idea?

>
> I prefer the first style for a couple of reasons.
Okay...I can give it another try.
>> 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.
>
> It should be relatively simple.  A filter runs before the action ever 
> executes, so
> it doesn't have to know anything about the way the action is being 
> handled.  It should
> simply be a matter of wrapping an old before_filter in a Proc that 
> checks to see
> if @request.method matches a list of allowed methods.  Maybe 2 or 3 
> lines of code.
>
> I was thinking of using Peter's proposed syntax, which adds the 
> :methods condition:
>
>   before_filter :auth, :methods => [ :post, :put, :delete ]
>
> So in this example we'd run the rails auth method whenever the HTTP 
> request
> method is either POST, PUT or DELETE.  Of course, you could still 
> restrict
> it further by using the :only condition to specify exactly which
> actions/resources to apply the filter to.
>
That sounds good.


>
> Its supposed to be included at the top of the controller (just like 
> yours)
> with "include RestController::Base".
>
Cool.

Thanks,

Charlie

> __________________________________________________________________
>
> Dan Kubb
> Autopilot Marketing Inc.
>
> Email: dan.kubb at autopilotmarketing.com
> Phone: 1 (604) 820-0212
> Web:   http://autopilotmarketing.com/
> vCard: http://autopilotmarketing.com/~dan.kubb/vcard
> __________________________________________________________________
>
>
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.2.2 (Darwin)
>
> iD8DBQFELydh4DfZD7OEWk0RApinAKCfLe+LM9oo1XhpQcz58LlE0QjJNQCgp1RP
> lEnzmkMObzdguxA1zu1e9aM=
> =6tBC
> -----END PGP SIGNATURE-----
>
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3166 bytes
Desc: S/MIME Cryptographic Signature
Url : http://microformats.org/discuss/mail/microformats-rest/attachments/20060402/a6259952/smime.bin