What RESTful API would you use for a turn-based game server?
How would you model a turn-based game server as a RESTful API? For example, a chess server, where you could play a game of chess against another client of the same API. You would need some way of requesting and negotiating a game with the other client, and some way of playing the individual moves of the game.
Is this a good candidate for a REST (RESTful) API? Or should this be modelled a different way?
Answer
I'm thinking something like:
/game/<gameID>/move/<moveID>
as far as the basic resources are concerned. I'm not sure how to handle the "has the other player moved yet?" idea, though. I've thought about simply having the GET request block until the move is played--i.e. my client would PUT the coordinates of my move to
/game/13/move/1
and then would GET
/game/13/move/2
The server would not respond immediately, but keep the connection open until the other player moved (i.e. PUT to that location). Is this what nakajima is referring to as "comet-esque"?
Charlie, I'm not quite sure what you meant by the "token" for whose turn it is--does this solve the same problem without the need for polling or a blocking connection?
For player IDs, does it make sense to model those as a resource in part of the URL? I was planning to simply use HTTP user authentication (where the user/pass is sent as part of every request). You could still GET most resources without authentication, but if you tried to, say,
PUT /game/13/move/2
it would give you a permission denied error if you didn't have the correct credentials for that game.