REST API and nested resources design on POST


#1

I’ve got a situation where we have to create a “user” and “street address” together. A user may have multiple addresses but during register we collect just the first address. Its a requirement that we don’t create the user until the whole dataset is valid.

To create users we have POST /users

and address POST /addresses

With the current implementation, we’d try to create the user and it would save but then there would be validation errors on address, now we have a user in the database and a address thats not saved.

If the user decides not to continue we now have a dead user in our system or for that matter any other kind of related data, where you have such dependencies.

Question: do we introduce some kinda of draft state, so we can delete the user at a later date, say 24 hours later.

or do we nest the address under user during POST

{name: 'x', addresses: [{line_1: 'x'}]}

This means we should never get into a state where the user is created and the address isn’t, considering were using rails, as this would be done via a DB transaction.

I’m not sure what the best approach is, having drafts feels like a workaround, we could also delete the user if address validation fails but again feels wrong.

I know the idea is to have first class objects with the rest endpoints, but surly there must be better way to handle the above use-case without introducing draft states.

Thanks for the feedback