Suggested call flow for client

WARNING: THIS DOCUMENT IS DEPRECATED.
NONE OF THIS IS ACTUALLY BEING DONE
THIS EXISTS ONLY FOR HISTORICAL PURPOSES

Client stores user uuid

The client only needs to know the endpoint to get the user profile, and the rest of the API can be navigated with the returned hyperlinks (see HATEOAS if you're unfamiliar with this). As far as possible, the only argument required to open a view should either be a data object or a URL.

Call Flow:

• Client start --> request user profile (detailed) --> request each body followed --> construct a local database of events recursively, since events returned will have duplication --> construct news feed etc.
• User clicks on event --> get event (detailed) --> display interested users etc. (if necessary) along with other information contained in the response ?--> user clicks on a user --> request user (detailed)

Note:

• It is by design that a lot of redundant data will be returned with each request. The goal is to minimize the number of RTTs and have minimal interaction between the views of the client application.
• Recursion should not be a problem here since there will typically be only upto three levels of hierarchy. It is a necessary evil since if (say) a user is following Tech, then the feed should also include WnCCs events.

TODO:

• Return a flag with followed bodies of the user if the body is a child of another body the user follows to prevent duplicate queries.
• Implement an endpoint to get locations without detailed information of all events for map construction.
• Implement an endpoint to get featured events/bodies, which will be pushed to all users even if they are not following them