I'm trying to wrap a RESTful API around an existing implementation of a game.Here is a possible state diagram of a simple API design that comes to mind:I'm having troubles here because the existing domain implementation does not expose a list of moves. Instead it exposes the state of the whole board. A list of moves is not needed because the game does not support undos, or replays of games etc.I can think of a few options:I drill open the existing domain implementation and have it expose a list of moves for each game. So that I can implement the design from the diagram above.  I don't like this because having to change the existing domain model only to shoehorn it into an API has a bad smell.I design a state transition from /api/games/{id} with the extension relation newMove (or sth. similar) that allows a POST on the /api/games/{id}/moves resource. I will provide an API doc under /docs/rels/newMove. There won't be an implementation for GET on the list of moves.  Is this still RESTful? Must every RESTful resource have a representation and allow GET?  I find this appealing, though, because it means almost no additional server side logic.Of course there are more options. I could design the board as a sub-resource and implement a PUT state transition (+ link relation and docs) to update it.  I don't like this either. It means that I have to transfer the whole board, including the new move. Putting the whole board back to the server and have the server find out, which field has changed and also validate that only one field has changed, and what not, is needlessly complex. And it would result in some amount of additional logic on the server. Which again smells bad. So maybe PATCH instead?Finally I could design the board as a sub-resource and every field of the board as a sub-resource of the board (e.g. /api/games/{id}/board/5/11) and then implement a PUT to make the move.  This doesn't look bad. But it would be stupid to have the client get the state of the board by having it make multiple requests to get each field state. So there should probably be a representation of the complete board somewhere (e.g. /api/games/{id}/board or as a value of the game itself). In this case the question arises if it makes sense to implement GET for every field of the board at all because you ain't gonna need it.  So here again, must every RESTful resource have a representation?What is the simplest solution that still adheres to the REST constraints?One of the options above or maybe something completely different?
RESTful API design for an existing domain implementation of a simple game?
rest;api design;game development