I have three resource types -
write (these are three separate database tables, with
write having a foreign key dependency on
When character is created (upon a user save process), word and write also must be created. Character has a few values, but one of the most important is "active" - which is a boolean flag.
However, I don't necessarily care that the client knows the state of character in the database. I want a user be able to click something, and send a PUT request and the end result should be an
character in the database - whether or not that
character entry existed beforehand.
Ultimately what should happen for every PUT is that
character is created or set to
active status (which it will have by default if created - so basically,
character will exist in its default state after a PUT)
However, if the two children are created, I obviously don't need to create them again, nor do I want to reset them (they must track their state separately from their parent).
I have a few different ideas on how I could do this, but I'm not sure which is the most "REST"ful.
1) Create the records in the
write tables on the initial PUT request, and check for their existence and do nothing on subsequent requests. This is probably the easiest way/cheapest way, but it is not idempotent.
2) Create three PUT requests (with upsert functionality on the backend) on a client side action, with the end result being that a record exists in all three tables. Downsides of this are that I have to send three separate PUT requests (which is expensive), and they'd have to be timed correctly - very messy.
Do a GET call on any relevant
character a user tries to save first, and if it already exists, issue a PATCH updating its status to the opposite of its current
active status. This is a bit cleaner than #2, but also requires quite a bit of back and forth between client and server.
I'm not really sure exactly the best way to design the REST API in this context - can anyone give me advice on how they'd probably think it should be done?