REST - Canonical URI vs Relative URI (from a user point of view)

Question

I'm currently designing a service. It is a multi-tier service, that stores data from several clients using a REST interface.

It's not clear to me how should I accept a resource id inside the URI. Let's say the user 001 creates a resource, the first for him, but the 100th for the system.

What should I return when the user 001 makes a GET to /resource/1 (/resource/{id}). Should I display his record thus making the URI relative to the user performing the request? Or should I return the 1st for the system (denying it because it's missing the permissions to see it)?

I don't want to go deep inside the authorization stuff, but I'd like to know how should I handle this kind of situations. If I should prefer the latter then how can I make a user say "ok, give me the 1st resource I created" or "give me the 2nd ... ", "give me the last .. ", "give me the 100th resource I created"?

Answer 1

I dont claim to be an expert on REST but here is what I would probably do.

In your domain model, if a resource cannot exist without a user then its perfectly OK to model URL calls such as

GET /user/{userId}/resource  //Gets all resources of a user

On the other hand if resources can exist without users then this link on stackoverflow gives a nice way of modelling such calls.

RESTful Many-to-Many possible?

Another thing which we did for one of our projects was that, we had the linking table (UserResource table(id,userId,resourceId) ,and we had a unique ID for that and had something like

GET /userResource/{userResourceId}



 GET /userResource               //Retrieve all the resources user has access to

If security is your concern , there are links on StackOverflow on how to integrate Security with Rest calls. Ideally such logic should be handled on the serverside. You typically do not want to put that logic into the REST url.

For example if you get a call for

GET /resource  //Get all resources

Depending on who the user is, you return only that subset of resources he has access to.

Bottom Line : Dont build your resources around permissions.

Again, I am not an expert. Just my humble views. :-)