[uf-rest] Fwd: REST and Rails
cfis at interserv.com
Sun Apr 2 22:35:48 PDT 2006
> 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.
> The response pattern I normally use for web services (including AJAX
> clients) is the
> 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
> optimization of sorts. I'd prefer to keep the API simple and
> 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
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'
> r.put do
> # ... do some work ...
> render :template => 'collection_put'
> Then I'd say go with it. But if you attempt to use the patterns I
> 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
> 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
> 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
> 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
> method is either POST, PUT or DELETE. Of course, you could still
> 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
> with "include RestController::Base".
> 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 v22.214.171.124 (Darwin)
> -----END PGP SIGNATURE-----
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 3166 bytes
Desc: S/MIME Cryptographic Signature
Url : http://microformats.org/discuss/mail/microformats-rest/attachments/20060402/a6259952/smime.bin
More information about the microformats-rest