0

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"?

Lance Roberts
  • 22,383
  • 32
  • 112
  • 130

1 Answers1

0

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. :-)

Community
  • 1
  • 1
smk
  • 5,340
  • 5
  • 27
  • 41
  • What do you mean by "don't build your resources around permissions"? –  Oct 26 '12 at 22:43
  • And how would you handle a generic GET request to /resource that's meaning to list all resources available? –  Oct 26 '12 at 22:48
  • 1) if you have a get resource , the url should be like GET /resource/id and should not contain any user-id in it. Unless of course the resource belongs to a particular user. 2) generic get request would be like GET /resource – smk Oct 27 '12 at 03:13
  • Ok thanks for the explanation. Just one last question: so let's say we want to allow a user to list all his resources created... issuing a GET /resource should return the whole list (including others) am I right? What I say that I will only return his resources when he will "GET /resource"? So this request changes based upon user credentials... What I want is to avoid that a user can even see resources not belonging to him but possibily without being un-RESTful. –  Oct 27 '12 at 09:14
  • All of my resources are dependent on the user... and all resources are private (access is only gained if you're the owner)... I asked this question because I share your point of view, but most popular Google APIs only return your data even without specifying your user id inside the URI request. I think this is not a perfect restful way, but it's much simpler for end users. Of course I cannot allow people to get all resources (others included). I think at the end I'll follow the approach of using a meta-resource keeping resource private (only gettable by system admins) –  Oct 29 '12 at 23:28