Timeline for Unique ids for nested resources
Current License: CC BY-SA 3.0
5 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Sep 28, 2017 at 21:12 | vote | accept | CodeYogi | ||
| Jul 16, 2017 at 20:19 | comment | added | Samuel |
Well in the context of booking a room you would definitely need the hotel->room relationship. User's will probably want to search for hotels by location and then find a room within the hotel. Yes, the merchant layer seems mostly cumbersome. There's nothing wrong with using multiple strategies. You can have /hotels/9/rooms/2/facilities/7 and /facilities/7 be the same entity with the same operations available.
|
|
| Jul 16, 2017 at 18:10 | comment | added | CodeYogi | "after thinking about the problem a bit, it makes sense that you need to know the merchant and hotel before changing a room" why? now, suppose I add facilities which are part of the room so to update a facility I have to remember merchant id, hotel id, room id and at last facility id, right? | |
| Jul 16, 2017 at 10:21 | comment | added | CodeYogi | Mostly the users will be booking rooms via APIs. Generally merchant should be invisible because who cares about who owns the hotel most of the time we know that which hotel we need and would be interested in booking rooms in it. | |
| Jul 16, 2017 at 8:54 | history | answered | Samuel | CC BY-SA 3.0 |