As Aurélien pointed out designing the URI structure is not a REST concern. You should follow the URI standard, which is very loose. For example it states that the path is the hierarchical and the query is the non-hierarchical part of the URIs. The uniform interface constraint of REST is about using standard solutions, and there is no such a standard as nice URIs, so from a REST perspective it does not matter how you construct your URIs, because they won't be parsed by the client (unless you use URI templates for templating purposes).
According to the HATEOAS constraint your client has to follow hyperlinks sent by the service. Those hyperlinks must be annotated with metadata regarding the semantics of them. That metadata can be any kind of linked data. Currently IANA link relations are the most typical (by non-RDF formats), but you can use schema.org actions, etc... (by RDF formats) as well. So the clients check the metadata of the links, and does not care about the URI structure.
The nice URI structure is important only for the service developer. It is important because of 2 things:
- It makes routing easier: you can map endpoints to controllers much easier if the URI is readable.
- You can check that you mapped your URIs to resources and not to operations. If your cannot clear every single verb from the URI, then something is wrong. For example by
POST /users/123?update=true&partial=true body you cannot remove the update. So possibly the HTTP method is wrong, because verbs go to there: PATCH /users/123 body solves the problem. Most of the verbs can be reduced to the standard HTTP methods, like GET, POST, PUT, DELETE, PATCH, etc... so in practice you (almost) never need a new method.
In my opinion the flat approach is better, because it's easier to parse. By finding things you usually rely on a single id, and not multiple ids.
/wepapi/patients/0/studies/12/images - This makes sense, because you are looking for images from the 12th study of the 0th patient. An alternative approach is /images?patient=0&study=12 or if the studies have a unique id, then /images?study=0_12. Btw. designing ad-hoc search queries is not the mostly elaborated part of REST. With simple queries you can manage it using the query part of the URIs.
REST is not something you can currently learn from practice. Most ppl never read or understood the theory, so there are a lot of flawed tutorials out there. You probably have to start with the Fielding dissertation and some additional dissertations, for example this one. There are a lot of interesting and potentially useful projects still under development, like Hydra, RESTdesc, etc. So REST implementations are far from an elaborated technology. We probably need another 15 years, or more...
