Hierarchy in REST API

Question

I have a hierarchy like this:

Work Experience (like SomeCompany.com)
└─Roles (like Project Manager)
  └─Projects

So user can add his Work Experience. To that he can add roles with specific projects.

I would like to GET projects for the user id 1, but there is only relation between projects & roles. Do I really need to make like 4 requests to get Projects?

Get User
Get Work Experiences
Get Roles
Get Projects

So if I have more roles for different work experiences, I would have to make 20 requests just to get my projects. Isn't it not efficient? I would have to load some unnecessary data...

Is it possible to create just endpoint: /projects and filter it by user id ?

How it should be managed on API? For me, as frontend dev it looks quite not efficient, especially when people use mostly mobiles, so requests like this will kill your battery pretty quick.

How do you guys handle relations like this?

Thank you!

whats stopping you to get all data for a user and filter out what is required to be displayed on the screen.. If that has a challenge with the size of data and this is a specific endpoint you would need, you may design it as GET : ://user/{uid}/we/role/project — hImAnShU, Aug 09 '17 at 16:58
I am working on the frontend side of the project, and our backend guys came up with solution I mentioned above. The think you proposed would be ideal in my world. They are saying that there is to much circulations... — crotoan, Aug 09 '17 at 17:05
if you think that was fine, you can approve it as correct answer.. thanks — hImAnShU, Aug 09 '17 at 17:09
Not sure.. I am sure that above is the not the real use case.. may be the real use case have nested objects or some thing like we->role->project->{we->role->project->{..}}.. and so on.. Other than that, it's only a matter of having multiple loops.. for that i don't think a backend developer will ever complaint.. :) — hImAnShU, Aug 09 '17 at 17:15
"Is it possible to create just endpoint: /projects and filter it by user id ?" - yeah, just do that, like this `/projects?userid=123` — Vanity Slug - codidact.com, Aug 09 '17 at 17:51
[this question](https://stackoverflow.com/questions/20951419/what-are-best-practices-for-rest-nested-resources) is mildly relevant. — Vanity Slug - codidact.com, Aug 09 '17 at 17:55
See also: https://stackoverflow.com/questions/25872501/restful-flat-hierarchy-vs-dynamic-hierarchy-for-search-resource https://stackoverflow.com/questions/21067968/rest-resource-path-design https://stackoverflow.com/questions/15259843/how-to-structure-rest-resource-hierarchy https://stackoverflow.com/questions/7104578/rest-complex-composite-nested-resources — Grigory Kislin, Mar 10 '19 at 20:29
See [What are best practices for REST nested resources?](https://stackoverflow.com/questions/20951419/what-are-best-practices-for-rest-nested-resources) — Grigory Kislin, Sep 07 '19 at 11:05

score 0 · Answer 1 · answered Aug 09 '17 at 17:08

whats stopping you to get all data for a user and filter out what is required to be displayed on the screen..

If that has a challenge with the size of data and this is a specific endpoint you would need, you may design it as GET : <host>:<port>/<context>/user/{uid}/we/role/project

score 0 · Answer 2 · answered Aug 09 '17 at 23:06

Your API's entities shouldn't bee too tightly coupled. If you need to get eg. all projects for a user, there should be a user_id in your projects table for example, then go for eg. /users/<user_id>/projects.

If projects would be standalone and listable, a /projects would only list the projects (paginated etc).

Personally, I tend to follow the RESTful API approach and I've found it's really helpful. This page and this tutorial might help you understand how to better organise your RESTful API

Hierarchy in REST API

2 Answers2