Let's say I'm building a trivia game where users can create games with exactly 5 questions and 4 options (games, questions & options have their own database tables) for each question and assume I'm using a front-end MVC and a backend API.

I've always had this dilemma as to how the API should be designed.

Should I -

1. have individual APIs for games, questions & options? In which case, when I'm creating a new game I'll need to make ton of API calls to setup all questions of the game and their options. But then when updating the game or any of it's questions, it's a simple update API call for each resource we're dealing with.

2. Keep the game as an aggregate of game details, questions & options and let the backend receive this as a whole and let the backend iterate through questions and options and create them in the database and do the same when updating.

Which would you prefer or is there a hybrid solution here?

Thanks!

Let's say I'm building a trivia game where users can create games with exactly 5 questions and 4 options (games, questions & options have their own database tables) for each question and assume I'm using a front-end MVC and a backend API.

I've always had this dilemma as to how the API should be designed.

Should I:

1. have individual APIs for games, questions, and options
2. keep the game as an aggregate of game details, questions, and options and let the backend receive this as a whole

The disadvantage of 1. is that when I'm creating a new game I'll need to make ton of API calls to setup all questions of the game and their options. However, when updating the game, or any of it's questions, it's a simple update API call for each resource we're dealing with.

The advantage of 2. is that the initial setup is a single API call. The disadvantage becomes apparent when updating the database: the backend has to iterate through all the questions and options again, even if it's only a single question that needs to be updated.

Am I missing any other aspect of these two design decisions?