-1

I am developing REST API using node.js and Express.

I have Houses collection and Rooms collection. Every Room belongs to exactly one House for it's entire lifetime.

I'm not sure how to design API endpoints for managing Rooms. My problem is that if I use endpoints like /houses/:house__id/rooms for creating a room, getting all rooms or just one I still would need endpoints like /rooms/:room_id for deleting a room. It it okay to divide creating, returning and deleting of Rooms in such a way?

Or maybe I should structure my API in a way where /rooms would handle creating, deleting, modifying and getting one room but still keep /houses/:house_id/rooms so that all rooms for a house can be retrieved?

I'm fairly new when it comes to creating REST APIs and to be honest I didn't find any help in articles about best practices and such.

1

One way of looking at this is to ask whether the system itself will need to deal with rooms outside of a house context.

If not, then APIs like /houses/:id/rooms/:id make sense and are natural. You can keep a good nesting and do PUT/GET/DELETE on the latter to alter a particular room of a house.

On the other hand if rooms can be dealt with outside of a house context. Like doing a search for all rooms in all houses which have an area larger than a certain size, then you need the form with /houses/:id and /rooms/:id.

REST guidelines won't really help that much - you're interested in how to structure the problem domain, whereas REST concerns will be several layers deep. But once you have a good structure, RPC or GraphQL is just as good.

In DDD terms, you're asking whether rooms and houses are different aggregates, or whether there's just a single one - the house, with an entity that's a room.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.