Christian wrote:
> I john,
>
> I 'm not sure there's some kind of preferred pattern for that, you
> should decide what you like best...
> The way we do it here is to always have the plural serve the list
> (/accounts) and the singular allow access to the resource (
> /account/{id} ) which forces you to write 2 different classes but
> makes sense.
>
> Christian
>
As Christian points out, it's a lot of personal preference on this, but
my preference would be to use "/accounts" and "/accounts/{id}". The
implication is that an account with a specified id "is-a" member of the
accounts collection. Of course, I came to REST primarily through Ruby
on Rails, and this is the pattern that Rails follows, so I was already
used to it :-).
Regarding one resource class versus two, this approach gives you the
option to do everything in a single resource class, or to separate them
with a sub-resource class for the items. Most of the resource classes
I've written so far are so small that there is no particular reason to
separate them based on line count or anything (my business logic is in
separate classes that the resource classes delegate to). However, on
more than a few occasions I've needed to share some logic between the
GET methods, and having everything in one class makes that a little easier.
Craig
>
> 2008/10/9 John O'Conner <john_at_joconner.com <mailto:john_at_joconner.com>>
>
> Thank you in advance for being patient with a REST and Jersey noob.
>
> I have created a root resource call AccountsResource with the
> @Path("/accounts"). This class returns a list of accounts in the
> system.
>
> At this point I could create a subresource /accounts/{id} that would
> retrieve information about a specific account....or I could create a
> root resource called AccountResource that would always require an id,
> ie /account/{id}.
>
> What is the general pattern for handling containers and then specific
> items within the container. Is /accounts/{id} correct for retrieving a
> specific account...or is /account/{id} the preferred pattern?
>
> Regards,
> John
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
> <mailto:users-unsubscribe_at_jersey.dev.java.net>
> For additional commands, e-mail: users-help_at_jersey.dev.java.net
> <mailto:users-help_at_jersey.dev.java.net>
>
>