Suppose the following:
Building has 0...n Rooms,
Room has 0...n Seats.
I am implementing a REST API which accepts data from different companies, with the caveat that the companies must be able themselves define the id (reference) of the entity. I'm generally unable to make any assumptions about those ids, other than being compatible with a HTTP URL. This means there's no guarantee ids are unique across companies, or even within a company (e.g. two rooms could have the same id but be linked to different buildings).
Since its possible that two companies would have the same id for a Building, I've decided to treat
buildingReference as a composite id. The API endpoints I came up with are as follows:
I have some doubts whether this is a good idea. Among other things:
- Most APIs I've come across only use a singular id
- If I ever decide to expose GET
/seats, I'd have to return more and more fields to make the resource uniquely identifiable,
companyId, buildingReference, roomReferencefor room and
companyId, buildingReference, roomReference, seatReferencefor seat
I could possibly get rid of
companyId by requiring that the
buildingReference be some kind of String concatenation of the two, e.g.
CompanyOne-1234, but that doesn't strike me as a great idea either.
Are composite keys like this a good idea? Are there better alternatives?