I have a bunch of REST webservices that my client uses. For instance, to create a user, I have

POST /users

and to modify it

POST /users/{id}

The problem is, some fields, as marketArea, are allowed to be edited only by employees, that will have an EMPLOYEE role. Other fields, as name and age, are editable by end users, that will have a USER role. As I have access to endpoints restricted by role, in this case there is an obvious collision.

I could easily go around the problem by setting different paths:

POST /users/{id}/public (require USER)

POST /users/{id}/internal (require EMPLOYEE)

But this doesn't feel right to me. What's the best practice in this case?


Without knowing more, and without adding a ton of work, I would suggest that you use one path and do a permission check on POST to make sure that the user can update the fields that they've updated. Respond with a 403 Forbidden if a USER tries to edit an EMPLOYEE field, or vice versa.

  • Agreed. Just check the role before processing the change, and either ignore the attempted change or generate an error message or response if the role doesn't permit the change. Internal permissions checks generally shouldn't be part of the visible URL path. – Todd Knarr Mar 30 '16 at 14:52
  • Doesn't that entail mixing the security and business layers? I'm a bit lost here, but I think then I'd nedd either the role at application level, or the request object at security level (Spring security in this case) – user3748908 Mar 30 '16 at 15:04
  • 2
    This isn't so much security as permissions, and permissions are part and parcel of the business rules. You can move some of it to the Spring security component, eg. checking whether they have any access to edit a given user, but trying to move all of the permissions logic up there over-complicates things immensely and as you've found causes all sorts of design problems because you're trying to control what's inherently a question of application logic flow from a component that isn't connected to that logic flow. – Todd Knarr Mar 30 '16 at 16:50

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.