I’ve tried both design strategies – nested and non-nested endpoints. I’ve found that:
-
if the nested resource has a primary key and you don’t have its parent primary key, the nested structure requires you to get it, even though the system doesn’t actually require it.
-
nested endpoints typically require redundant endpoints. In other words, you will more often than not, need the additional /employees endpoint so you can get a list of employees across departments. If you have /employees, what exactly does /companies/departments/employees buy you?
-
nesting endpoints don’t evolve as nicely. E.g. you might not need to search for employees now but you might later and if you have a nested structure, you have no choice but to add another endpoint. With a non-nested design, you just add more parameters, which is simpler.
-
sometimes a resource could have multiple types of parents. Resulting in multiple endpoints all returning the same resource.
-
redundant endpoints makes the docs harder to write and also makes the api harder to learn.
In short, the non-nested design seems to allow a more flexible and simpler endpoint schema.