Obviously a RESTful API could contain base routes such as:


And nested routes such as:


But what about the following example (Route A):


So all players, for all teams that are in a certain competition?

Q1: Would this contravene REST design?

Q2: Presumably it does, but is there any documentation that explicitly states this? I have done some research and cannot find anything that rules it out as the examples are all very simplistic.

You could implement (Route B):


instead, and then underneath the logic would ensure that the players are not ALL players (as in api/players) but take into account team and therefore competition - so that players that are without a team are excluded.

However, moving away from this simple example to a more abstract model, there might be scenarios where Route B might be more confusing to an API consumer than Route A.

Q3: Would there ever be a justification for implementing a nested route (like Route A) without all identifiers at every level?


1 Answer 1

  1. No. REST doesn't care about how your organize your resources, only that individual resources are identified by URLs and that resources are discoverable from other resources. If api/competitions/{id}/teams/players makes sense for your application then use it, as long as users can find a link to it.

  2. Roy Fielding's dissertation on Representational State Transfer, specifically sections Resources and Resource Identifiers and 6.2 REST Applied to URI. Also look into HATEOAS (Hypertext as the Engine of Application State).

  3. Yes, if it is both understood by and convenient for users of your application.

REST is a high-level architectural concept. It's not concerned with how you nest your identifiers. That's up to you and your application requirements. Do what makes sense and be obvious about it.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.