Re: [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

following:

  GET    - 200 OK         - Response Body

  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

and if I need to know the current state of the resource I'll perform a

The response pattern I normally use for web services (including AJAX clients) is the POST - 201 Created - No Response Body, Location header to newly created resource 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, 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


above, I don't think you'll see it too often.


to keep as much as I can by sticking with conventions by default.

Then I'd say go with it. But if you attempt to use the patterns I outlined 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

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.

  before_filter :auth, :methods => [ :post, :put, :delete ]


it further by using the :only condition to specify exactly which
actions/resources to apply the filter to.

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: 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

That sounds good.

with "include RestController::Base".

Its supposed to be included at the top of the controller (just like yours)

Cool.

Thanks,

Charlie

__________________________________________________________________

Dan Kubb
Autopilot Marketing Inc.

Email: [EMAIL PROTECTED]
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-----

smime.p7s
Description: S/MIME Cryptographic Signature

_______________________________________________
microformats-rest mailing list
microformats-rest@microformats.org
http://microformats.org/mailman/listinfo/microformats-rest