Restful api design for admin and non admin accounts

Question

Facing problem on how to design api for admin and non admin account. I following MVC pattern, where controller will map to a uri.

Make up scenario:
Let said I have a system that allow user to redeem gift after they spend money on buying merchandise and collect points.

My system has a user profile, gift, and redeem table. Each user can redeem many gift and each gift can be redeem by many user. (Redeem is the junction table).

To access user profile, the uri will be like this:

GET /user/0001

To redeem a gift

POST /user/0001/redeem {"amount":1, "address":"old address"}

Everything seem nice and tidy up to this point. Now the problem arise when the redeem need to be approve by a admin user

So to update the redeem to approved status

PUT /user/0001/redeem/100 {"status":"approve"}

User can update the shipping address where the gift will be ship to

PUT /user/0001/redeem/100 {"address":"New address"}

Now I facing the following problem:

1. If 2 path point to uri, the controller will have 2 different handling code in the same function.1 if block for admin, 1 if block for user.

If I add a admin in front of the uri (admin/user/0001/redeem/100). 2 different path will identify the same resource.

2. To identify user identity was done on the Authorization header (Authorization="USERNAME:SECURITY_HASH"). Is this a typical restful approach?

3. I cannot differentiate user role because the admin and user was store in diffrent table. So if the uri indicate the user role, this will make things easier. I do not want to always query for admin table before user.

Answer 1

I would do the following:

1) have URL like POST /admin/user/1000/redeem/approve

Reasons:

• I don't want to expose the knowledge about which field in user record has to be changed to approve voucher

• I prefer to keep all admin actions separate from normal user actions

2) One of the "usual" ways is to have a (periodically renewed) session cookie (not related to username or password hash) that is issued after successful login and then separately a mechanism that would associate this cookie with username and check whether for this username the given action is allowed.

Reasons: you reduce the danger of exposing the information about your users. (This approach might be still vulnerable if the attacker steals the cookie, but so is the other one).

3) That you store admin and user data in different tables is not an excuse if we talk about the security :) Using the cookie mechanism described above might help here, but you'll still have to establish the way of verifying that given user can invoke given method.