So I am building a REST api and I am struggling to handle deeply nested relationships. Here is an example of some of the resources I have:
Profiles - a user can be a client or vendor profile.
Events - client profiles can create events (eg. social events which have attributes such as time, name, location etc.)
Tasks - Under an event, a client profile will create a "tasks" that need to be completed by a vendor profile for THAT event (eg. A task could be providing Photography service for an event).
Job requests - Once the client profile has created tasks for their event, they can send out job requests for each task to vendor profiles (here the vendor profile has the opportunity to accept the job request and become HIRED/ASSOCIATED to the the task).
I am also using a token based authentication scheme.
My question: How should I go about designing the URLs? I have contemplated over producing flat URLs likes
I suggest to use flat structure:
/tasks/ /profiles/ /events/
Because it will be possible to show events that are related different profiles and tasks that are related to different events. From frontend view there is a really small difference between
/profile/<id>/events/. Nested structure of your application should be described on model level and in documentation.
This question is not related to API endpoints structure. Lets say that user wants to reach event. Regardlessly to the endpoints structure - you need to check has user access to this event or not. So you have
event instance and can check user access to model field
profile if it is necessary.