0 Replies - 600 Views - Last Post: 13 December 2016 - 11:55 AM

#1 Zel2008   User is offline

  • D.I.C Addict

Reputation: 17
  • View blog
  • Posts: 893
  • Joined: 06-January 09

Handling REST user roles

Posted 13 December 2016 - 11:55 AM

Hi all,

I'm trying to work with a REST API that has multiple ways of doing essentially the same thing, like this example to get profile images:

/api/admin/profile-images - get all administrator profile images
/api/admin/profile-images/group - get all group profile images as administrator
/api/images - get all public profile images
/api/images/groups - get all group profile images
/api/profiles/images - get all pending profile images



Obviously, these URLs (and the corresponding code) are all over the place. The issue is, though, that all these APIs refer to a different role in the system. We're in the process of standardizing how the profile images are accessed, and each of these endpoints will use that methodology, with each role also having some unique parts. But, what, do you think, is the most intuitive way to handle the URLs? Would it be:

/api/admin/profile-images
/api/admin/profile-images/group
/api/public/profile-images
/api/groups/profile-images
/api/pending/profile-images



or:

/api/profile-images?access=admin
/api/profile-images?access=admin&type=group
/api/profile-images?access=public
/api/profile-images?access=group
/api/profile-images?access=pending



My instinct is that the second type is cleaner, and the first can cause confusion in URLs and duplicated code. But, I've also seen places that say you should separate your roles as if they were resources, like:

/api/admin
/api/public
/api/group
/api/pending



What do you all think, which general structure is best to handle roles?

Thanks,
Zel2008

Is This A Good Question/Topic? 0
  • +

Page 1 of 1