As part of building the front-end to the shared web side aspect of the cluster game, I’m starting to lay out the RESTful interface to the database at the back-end of the server side.
I’m looking at several main categories using query parameters to filter results on aggregate areas.
Returns a list of player names and ids. Details of a specific player can be retrieved (and changed) by accessing the player by player id as a sub-resource. Permissions do apply here…a normal player can only view or edit the details for their own information. An administrator can view and change information for any player.
- id (immutable after creation)
- name – Unique, human readable user name
- is email public
- password (settable only)
- date joined
- date last activity
Returns a list of games in the database. With query parameters this can return games containing only a selected player or players, games that are in progress and perhaps other subsets of all stored games. Details of a specific game may be retrieved by game id. For normal players, only the details that their player identity has access to may be retrieved. For developers all details are visible and subject to modification.
- player ids
One entry for each turn in the game so far. All open if the game is completed otherwise only information visible to this user is present.
- turn number
- units list
- unit id
- unit type
ship type, planetary resource type, population
- location type
space or system or planet
- player id
- technology list
- player id
- technology id
- moves list
- current turn
- moves submitted
(may be part of the turns container)
- final scores if completed
Options that relate to new games being started. Global lists (start information, admiral information and such). Generally these will only impact newly created games. Selected items may affect all games.
Audit log recording changes made using administrative privileges.