RESTful show or index?

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

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

On Nov 2, 2007, at 12:23 PM, monkeyten wrote:

应用宝官网-全网最新最热手机应用游戏下载

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

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

On Nov 2, 2007, at 1:03 PM, monkeyten wrote:

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?

Yeah, looks clean to me.

– fxn

5

Xavier N. wrote:

messages/recent/30

with 30 being some sort of period parameter?

Yeah, looks clean to me.

Clean, yes. RESTful, not so much.

You pose a good question, monkeyten, and I’m afraid I don’t have an
answer. I never really caught on with REST. It looks sweet, and I dig
the ideals, but it’s so hard to implement. Your situation is just one of
many “edge cases.” Others I’ve run into are…

A query from the same table for objects of varying statuses. Say I want
a list of all purchase order objects whose status is completed. Per my
understanding of REST, I should probably have something like…

completed_purchase_orders/index

And for pending purchase orders…

pending_purchase_orders/index

In the OP’s situation, again per my understanding, I’d say you have a
resource called recent_messages…

recent_messages/index

In fact, I’m not so sure about the index method at all – can someone
with more experience in REST throw some knowledge on me? Here’s how I
currently see it…

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. Why are we using it?
If I want to access a list of all my users, shouldn’t it be…

user_list/show

And not…

users/index

In the past month or so I’ve become really interested in REST. Primarily
because of the write-ups over at Pivotal Blabs detailing a controller
formula, RESTful authentication and CUDly models. So, I’d LOVE to start
using it full-throttle with no exceptions, but sometimes it feels so
contrived… :frowning:

6

Xavier N. wrote:

On Nov 2, 2007, at 4:29 PM, Daniel W. wrote:

Xavier N. 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

Interesting. I wasn’t aware of the :collection directive. (I’ve never
used map.resources.) I read the docs just now…

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

–> GET /messages/rss (maps to the #rss action)

also adds a named route called “rss_messages”

So now there’s another action called rss, which is accessed via get.
Okay, so… I guess I was wrong in thinking that the controller actions
were limited to the four verbs… I’m so confused.

Accessing a resource… I guess, that’s not a nested resource is it? No,
a nested resource is one whereby you access more than one resource.

Ugh… okay, what about an example of something that is NOT RESTful?
Here I’ll paste a controller from work. This is one of the larger (300+
lines) ones. I didn’t write it.

class InventoryController < ApplicationController

def search
…
end

def component_view
…
end

def order_parts
…
end

end

Is that RESTful? It sure doesn’t feel RESTful.

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.

Yes, you’re absolutely correct. I guess the question is… what
constitutes a good subset?

7

On Nov 2, 2007, at 4:29 PM, Daniel W. wrote:

Xavier N. 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

8

On 11/2/07, Xavier N. [email protected] wrote:

Why is it not RESTful?

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

9

On Nov 5, 2007, at 3:50 PM, Michael G. wrote:

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

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

10

On Nov 5, 2007, at 4:47 PM, Xavier N. wrote:

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.

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