Design the Data Model

The data model follows the API design. A good place to start is with one table per resource. In this case, we would have a table that lists the collection of games.

Games data model

Each game would also have its own properties to capture the game state. This might all fit into one table, called games, that has the following fields:

Field Name	Description
game_id	A unique, non-guessable, ID for each game
user_name	The name of the user as submitted
language	The language that the game is using
secret_word	The secret word the user is trying to guess
guessed	Letters guessed so far by the user
usage	Usage example for the secret word
reveal_word	Blanks and revealed letters so far
bad_guesses	Number of incorrect guesses so far

These fields contain enough information to track each game and its current state.

Trimming down the model

For each field, we can ask whether it is necessary and sufficient to create a working API. That is:

1. Can the API respond without it?
2. Does it store enough information so the server can compute the response to the client?

Clearly, the game_id is needed. However, the user_name and language are, at this point, not used after the game is created. While they could be useful, there was nowhere in the story where the client needed to receive them. The secret_word and guessed are essential to a game since the server must determine whether ...