Overall Application Design/Routes

kelly-ry4n commented 10 years ago

I propose the following routes over a JSON API for communication

/, /index -> Homepage. Button to create new game. List of existing games (click to join/spectate).
/chessers -> actual game html
/api/v1/board_state/:id -> API endpoint for serialized board to be parsed from clients.
/api/v1/game_id -> API endpoint for getting the gameid for a session. Could also inline this into /chessers
/api/v1/change_board_state/:id -> Send updated gamestates after a move here before displaying to user. It will respond OK if the moves is permitted, and then client can update display.
/api/v1/my_turn -> responds T or F, in case a client loses its place it can get it back. Could be combined with board_state
/api/v1/board_state/:id/:movenum -> List of gamestates... could be used for replays, etc.

Clients can poll these say every second, or we can use a longlife connection which the server writes to when it has data, or some combination of the two.

Can you think of any other functionality we need to expose in the API in order to play between clients, or any connivence endpoints you'd like as the frontend guy?

Dakkers commented 10 years ago

sending the entire board state over is quite doable as I ended up creating an object that has a grid number (tile) for its key, and the piece occupying it (or null) for its value. could just send that.

I'll update this momentarily.

Dakkers commented 10 years ago

and by momentarily I meant a few hours later. and I actually have nothing to add yet. too tired to think

kelly-ry4n / chessers

Overall Application Design/Routes #5