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

New Topic/Question
Reply



MultiQuote

|