When designing a RESTful API should resources which are dependent on others be modeled as sub-uris or should they simply reference each other?
E.g. presuming a door is always dependent on a house then
/house/73/door/1 or
/house/73 /door/1044 where house and door include references to each other?
Most RESTful APIs I have found are quite flat so I would value references to any which do have more complex relationship dependencies.
Regards
In UML terms, if the relationship is that of Aggregation, then you use a flat hierarchy with links between things, whereas if the relationship is that of Composition (i.e., the lifetime of a door is strictly bounded by the lifetime of a house) you use sub-resources.
I'm not suggesting drawing a UML diagram! But it does help to have in mind that distinction. (You could also model the Aggregation case by having sub-resources that are just redirect to the real ones; redirects are RESTful. OTOH, I don't actually like doing that; I prefer to make any relationships explicit and to keep the number of redirects down.)
Just remember that URIs are an implementation detail of the server. If you can model them as flat resources then do so. It will be easier for the server to handle them.
If the identifier for the door is not unique across all houses, then your server is going to need to know the house and therefore you need to include the house in the URI.
The relationships between the resources should be modeled by links within the returned representations. i.e. Your house representation should probably contain links to all of the door resources in that house. I would recommend trying to avoid using the URL structure as having some domain meaning.
Only use a hierarchy if it is needed to uniquely identify the resource.
73is your primary key in a database, you won't be able to merge databases that easily...