Deciding on the correct RESTful URL design
- REST doesn't care what spellings you use for your identifiers.
- "Resources" are integration resources, not domain entities.
So, the question is which scheme makes more sense and should I rely on the framework like Spring to provide me the details or I should design my API endpoints in a stateless fashion although it seems redundant?
If you were creating a web site, how would you do it? From there, think about how you would do it with a machine readable web site. Presto! you have yourself a REST api.
You would probably have some sort of a home page, with a link on it saying something like "My Tickets". For the operators, it would be a view with perhaps a heading and a list element with their own tickets in it. For the managers, it might be the same view, but with an additional link to another page that includes the overview of the teams tickets, or it might be the original view with additional elements that show the team's work.
A key idea of REST is that the client and server have a common understanding of the media type, which is to say the processing rules, which can include support for optional elements. The server guides the client by choosing which elements to provide in the representation.
This suggests that a given entity in your domain model might have more than one "current" representation. So you could achieve that with two different resources, each of which doing a particular mapping from the current state to a representation.
So Bob's requests could be redirected to the resource for individual contributors
But Alice's requests could be redirected to the resource for managers
Just like the way we do things in the web, the clients don't care what the spellings of the URI should be; they just follow the links that are provided to them.
So in your first example
Is perfectly fine. For managers, you could analogously do
REST doesn't care about spelling, but relative references do; dot-segments are fine for paths, but there's no analogous spelling that allows you to move around on the path while preserving the query. In other words, if you have a lot of related resources, it's more useful to have them share a common path than a common query.
Is perfectly fine too.