I ended up with a similar issue and used Router.LAST, putting the more
generic URIs first, and the most specific ones last. (ie, /user/{id}
first, then /user/list later).
In the end though, I ended up moving to /user/{id} and /users as Adam
suggests. It's definitely made our client requests and Resource
implementation simpler.
Valdis
Adam Taft wrote:
Generally, when one wants a list in REST style, you have two options:
/user/?additional¶meters
/users/additional/parameters/
Either way allows you to have /user/{ID}/ as a valid url.
I don't know enough about the RESTlet API to tell you, but I think
your {ID} will likely eat your /list/ as you are experiencing. There
may not be a good way around it.
If you have to have it like this (without changing to one of the
"preferred" url schemes above), then you might consider looking at the
{ID} variable and if it .equals("list") forward it to the correct
representation.
The point is, I think you won't be able to have two separate Resource
classes for your urls. They'll have to be the same Resource and
you're going to have to change your representation whether or not you
have an ID coming in with the value of "list". Then, you have to hope
you never have a user that is created with a primary key of "list" as
well.
I'm sure a restlet guru will have a better idea. I just in general
think you should avoid mixing your "listing" urls with your "entity"
urls.
Adam
Jonathan Hall wrote:
Hi,
Is it possible to do this:
/user
/user/{id}
/user/list
The problem comes from the app thinking list is just a {id}
variable. I thought router.setRoutingMode(Router.FIRST) sounded like
it would pick the route I wished by the order they were attached.
In which case this would work:
/user
/user/list
/user/{id}
However, it seems to not work like that. No matter what order I
attach the routes they seem to end up in the same order in a
RouteList. I also need to have optional parameters attached to all of
the urls.
Any ideas?
Best Regards,
Jon
