[LRUG] REST and Associations
jonas.b at gmail.com
Thu Feb 22 15:06:13 PST 2007
Roland Swingler wrote:
> 1. From what I've read, I thought all urls were meant to be nouns in
> restland - how does having /posts/1;edit give you any advantage over
> /posts/edit/1 or /posts/1/edit ? A semicolon does not a noun make. For
> me this highlights a possible weakness in thinking of everything as
> nouns - see Steve Yegge's "Kingdom of Nouns" article -
REST seems to work very well for as API, but from my point of view it's
not a perfect match for web apps, since the server doesn't only need to
CRUD data, but also control the application flow etc. So I don't think
you can get a 100% RESTful web app.
In a way /posts/1;edit isn't RESTful. But the ";edit" doesn't actually
mean "edit this resource", just give me the edit form for this resource.
The actual update of the resource is done through a PUT to /posts/1,
which is clean and RESTful.
The HTTP methods/verbs don't contain the vocabulary to say that you want
a "new resource" form, or a "edit resource" form, so I think
resource/new and resource/id;edit are good workarounds.
> 2. What is the right way to do search? Are query strings still ok in
> urls? Is search a seperate controller?
From a REST point of view urls are opaque. The main idea is that the
url is the noun and you use different verbs (HTTP methods) to manipulate
/search?q=joe looks like a mix of nouns and verbs to me, so
/people?name=joe looks better. But again, both can be considered RESTful
in my opinion.
> 3. Similarly what is the right way to do sorting/pagination? For
> example when I GET /posts I may want to only return the top ten in
> html - but what about in the xml respond_to do I return all of them or
> just ten? Is the idea that *exactly* the same resource(s) are
> returned, no matter the mime type or can _what_ is returned vary as
> well as _how_ it is returned?
Not sure, but it seems like the "by the book" approach would be to
return the same data, no matter what mime type. To use
/posts?start=20&count=10 seems quite alright even for a REST/XML API.
> 4. The urls nested resources produces only seems to make sense for the
> new / index /create actions - by the time the resource has a unique id
> it already has a unique url, because the id is unique - but there
> doesn't seem to be any way to disable the urls you don't want.
You would probably need to create the routes manually (i.e. not use
I actually like the nested urls since by going from /parent/X/child/Y to
/parent/X/child I get to see all the children. It's not as easy to go
from /child/Y to /parent/X.
I'll pass on the remaining questions :-)
More information about the Chat