Suppose my system has Organizations which contain Departments which contain Work Areas, so it makes sense for me to query something like get /organization/o1/department/d2/workarea/w3/employees
to get a list of employees in Work Area W3 that's part of Department D2 that's part of Organization O1.
Let's further suppose that those numbering spaces are guaranteed separate and each item is unique, such that there is definitely no other Work Area W3 anywhere. The only Work Area W3 is clearly and uniquely part of Department D2. And so on up the hierarchy.
Two questions:
- Is it good design to support a REST URL like
/organization/o1/department/d2/workarea/w3/employees
(because it fully represents the resource) or is it better support something more like/workarea/w3/employees
(because it's guaranteed unique and the server knows what it's looking for)? - In implementation, is it good design to support the "long" resource path but also make everything but the last element optional? E.g.,
/[organization/o1/][department/d2/]workarea/w3/employees
with the optional bits in square brackets?
Curious about what is best practice, and why.
/workarea/100250/employees
.W3
sounds like a descriptive code that I might want to change in the future. And furthermore, I would keep the hierarchy out of the endpoints specific to work areas. If I want the hierarchy then I can get a list of organizations or departments, but if I only want work area employees then I don't want to have to craft a URL with organization and department.