RESTful show or index?

rubyonrails-talk
1

This one has been puzzling me and its probably fairly simple(!), so maybe someone could shed some light on it..

I have a resource called messages. By RESTful principles, the index method shows all messages and the show method shows a specific message. But what is a RESTful url (and method) if I want to show a subset of all the messages (e.g. last 30 days)?

Is it something like:

myapp.com/messages?filter=30days

or:

myapp.com/messages/30

The latter would mean that the show method was pulling a range (rather than a reference) which I assume is not the correct behavior.

2

If the number is not a parameter I'd publish instead

   /messages/recent

as

   :collection => {:recent => :get}

-- fxn

3

Yes it will be a parameter - sorry I wasn't clear on that one. Does that change your opinion in any way? What about:

messages/recent/30

with 30 being some sort of period parameter?

4

Yeah, looks clean to me.

-- fxn

5

Xavier Noria wrote:

messages/recent/30

with 30 being some sort of period parameter?

Yeah, looks clean to me.

Clean, yes. RESTful, not so much.

Why is it not RESTful?

The fact that the collection of recent messages is a logical subset of resources you want to publish means they have a URL, and the collection is retrieved through GET, that's what you accomplish with

   map.resources :messages, :collection => {:recent => :get}

From the rest of the reply you seem to assume that URL have to be a root URL as in

pending_purchase_orders/index

Which is not necessarily the case. Subsets are naturally accessible as subordinate paths of their superset's.

You've got four methods (verbs) at your disposal for acting on a collection of resources. Post, get, put and delete. Create, show, update and destroy.

Now, where in that list is index? I don't see it.

By convention Rails routes a GET request to

   /messages

to MessagesController#index, you no longer see the /index in the URL.

-- fxn

6

From what I have read on this list, I see two definitions of RESTful interfaces:

  (1) what RoR people say you should use (the standard 7 [or 8]) operations,   (2) What the world thinks of REST (far less restrictive than (1))

I follow (1) when I can, but fall back to (2) when I must.

--Michael

7

You quoted a question, were you giving an answer?

I have fresh in mind "RESTful Web Services", and know some Rails.

On the first hand I think /messages/recent/30 is RESTful, it is the URL of a logical resource. And easily doable with the builtin routes support in Rails.

On the other hand Rails uses conventions to route REST requests which are just fine. GET /invoices is expected to obtain a list of bookings. DELETE /invoices/{id} is expected to delete that booking, etc. That's what (2) expects (even in the case that (2) and (1) are not differente). I don't see any mismatch in the way things are published. Nested resources have natural routes....

The fact that the underlying controller method invoked is this or that one does not matter, you are not exposing Rails actions, you are exposing resources through URLs and HTTP verbs, who happen to be routed to actions internally. You may expose those 7 or 8 operations, or less, or more. As far as RESTfulness is concerned you still have resources, HTTP verbs, an comply with the uniform interface. No matter how many :member, :collections, etc. have published, you stay RESTful.

-- fxn

8

Sorry, there's a mix invoice/booking there.