Resource path handling between REST Layer and Service Layer

Question

What is a good way to handle "top-level" IDs in a Resource-oriented API path?

Consider a call to

GET /resourceA/12/resourceB/23

where A to B is a Parent-Child relationship and B has globally unique identifiers.

The REST Layer could simply do

return resourceBService.find(23);

But this completely ignores whether the user has "followed" the correct path, i.e. whether 23 is an actual child of 12.

So I think there are two options here:

1. The REST Layer always explicitly checks IDs in cases where they would go unnoticed. Drawback: It could overload the REST Layer with too much application logic. Also sometimes the REST Layer cannot check everything, so some checks need to be performed in the Service Layer anyway. This seems to split responsibilities.

2. The Service Layer always demands all Parent IDs for context, since we are dealing with Parent-Child relationships. Uniqueness of the child's ID in the database is a technical detail that should not be taken for granted. Drawback: I am modeling the Service Layer after a specific client (Resource-based). Maybe other clients don't need this approach at all and it would be cumbersome to use.

Is there a best practice?

• Ewan: do you mean this "REST Layer"? github.com/rs/rest-layer
• VoiceOfUnreason: You should probably review "Information Hiding" - especially Parnas 1971.
• Philipp Murry: @Ewan No I'm just talking about the Controller Layer that is calling the Application Layer
• Philipp Murry: @VoiceOfUnreason the problem is what constitutes "information hiding" depends on what design decision I make. if I decide to explicitly model the relationship as Parent-Child, then offering the method service.read(parentId, childId) does not violate encapsulation. if I decide the relationship is just an association, then service.read(id) is enough, as the model doesn't care about an arbitrary association inside the entity.

Answer 1

Uniqueness of the child's ID in the database is a technical detail that should not be taken for granted

I think I would disagree with this. Its part of the domain design whether the children only have meaning when linked to a parent, or if they are entities in their own right.

eg.

/album/AbbeyRoad/song/0 returns { "come together", the beatles}
song/0 returns error: makes no sense without album
song/come_together returns [{"come together", aerosmith}, { "come together", the beatles}]

If you go with a required parent id design, then your backend needs the parent id to complete the operation.

If you go with a unique id design, you don't use the parent/child resource path at all as it just makes everyone life hard for no reason.

• Flater: @PhilippMurry: it's pointless. However, if you look in the StackExchange URL, you get both the question ID and its title. The title is functionally irrelevant but is added for human eyes if they're looking at URLs. It's not pointless, but it has no technical justification and does not need to be validated as part of the fetch process.
• Flater: @PhilippMurry So if you want to add it, you do you. But it has to have a benefit of some kind, because you have to consider that your consumer now will be suggested to supply more information than they need, which is an added cost.
• Ewan: I think the name is prob added for SEO rather than humans, Also it doesnt seem to be used, you can change it to anything
• Ewan: @PhilippMurry I agree that its the domain decision that's important, not how its implemented. But not that the decision is an implementation detail. If you have had to make the decision to require the parent id, the factors that lead to that decision should make it impossible to accidentally add a unique id. eg song index in album
• Ewan: If your parent and childs all have unique ids, then it makes your interface worse to require both to retrieve a child