Q:

Unique ids for nested resources

I have couple of nested resources like Merchant, Hotel, Room. A merchant can have many hotels and similarly a hotel can have many rooms.
Right now for managing these resources I doing something like:
Create
POST api/v1/merchants/11/hotels
creates a new hotel.
Update
PUT api/v1/merchants/11/hotels/42
updates the given hotel.
Same for read and delete.
For rooms:
Create
POST api/v1/merchants/11/hotels/42/rooms
creates a new room.
Update
PUT api/v1/merchants/11/hotels/42/rooms/42
updates the given room etc.
In future there will be more nested resources like room facilities etc. and following this scheme will turn hairy.
I am in the early stage of development and I may expose these APIs for developers hence I can't change API scheme very quickly.
I am in doubt from day one regarding this approach. Can I assume that each entity has unique ID (which is true for now as I am using relational database and has its own table)? If yes, then the can I use these URLs for APIs instead of above ones?
POST api/v1/rooms
PUT api/v1/rooms/42
Etc for more nested resources.
Is there any violation of semantics or standard that I may be missing? I am using similar approach in views eg. in URLs in browsers which is looking ugly too.

A:

following this scheme will turn hairy

Can you explain why you think the nested design is bad?

Can I assume that each entity has unique ID? If yes, then the can I use these URLs for APIs instead of above ones?
POST api/v1/rooms
PUT api/v1/rooms/42

Typically each type of entity will have its own id space, and each instance will have an id from that space. Each room will have a different id from every other room. It doesn't have to be this way, but usually it is, and yes that would give you flexibility and allow you to adopt a flat structure like you're suggesting.
Originally I thought perhaps a flat structure would be better. It would allow you to manage a hotel or a room without having to know the parent entities, but after thinking about the problem a bit, it makes sense that you need to know the merchant and hotel before changing a room. Am I right in thinking that a hotel only belongs to a single merchant and a room belongs to only a certain hotel? If these are one-to-one relationships, then the nested structure makes a lot of sense.
The choice you make will ultimately be decided by your use cases. How are developers going to be accessing your API? Are they going to only be looking at one merchant? -- If so, you may want to not show them the merchant layer (lookup merchant from authentication). Are they going to be iterating over every room or hotel in the API regardless of merchant? -- If so, the flat structure makes a lot of sense. Answering these questions will help you decide how to structure your API, and you may decide you want both a flat structure and a nested structure to meet all your use cases.

