I'm a moderately experienced web developer (3-4 years' experience) just getting started with the BGA framework, and I've noticed something about how it works that seems strange to me. I'm well aware it's probably too late to change things but I'm just curious about the thinking behind why it's this way in the first place.
What puzzles me is that the Ajax requests that are sent when a player takes an action are GET requests, rather than POST or any other method - despite the fact that they almost always lead to changes in the game database. This is certainly against REST principles - although perhaps that's mostly academic here. One of the biggest arguments against state-changing GET requests is that search engine crawlers, or humans who can be persuaded to click on links etc, will unexpectedly cause these state-changing actions - but given that the URLs for BGA player actions are not linked anywhere, and rely on particular query parameters as well as being dependent on game state and so on, it seems hugely unlikely that any incident could occur that ruins a game. Although not impossible - if I'm in a turn-based game and I want to cheat, and know an opponent will take a few days over their next turn, I could in theory figure out what the URL would be for some particular catastrophically stupid move they could in theory make, and do some social engineering attack to get them to trigger that link. Actually, does the server even check that there is a user making the request that matches the user ID in the URL? If not a cheat could "make moves" for their opponents all by themselves!
But I'm sure there are at least some session cookies or similar involved - at least I hope so!
One other inconvenience of the GET request method is that it becomes hard to send structured data as part of a game action. In a POST request one could easily send a JSON body of arbitrary complexity. In theory a GET request could do the same by sending a JSON string as a query value - but this isn't' something that's really often done, and in any case wouldn't work in the BGA framework because the "action methods" only accept certain particular formats of data (for anti-cheating reasons, I suppose). I've already been struck with how awkward it is to send something simple like a list of card IDs to be discarded - you have to put all the IDs in a single comma-separated string, which admittedly isn't at all difficult but it becomes quite a bit of "boilerplate" to encode Javascript arrays this way on the client side then decode them to PHP arrays on the server side. And the complete inability to send more complex data like an array of objects (yes it could be done via JSON encoding/decoding but it feels like this would be discouraged, and you'd have to come up with your own validation on the server side to ensure the data is well-formed) also seems like a frustrating limitation.
Am I alone in feeling that this is all far from ideal? And are there good reasons it has to be this way, or is it just one of those historical accidents that came about and we're just now stuck with it because it would break too much to change it? (I expect it is, but I'd be interested to hear if there's more to the story.)
Thanks for indulging my question
What puzzles me is that the Ajax requests that are sent when a player takes an action are GET requests, rather than POST or any other method - despite the fact that they almost always lead to changes in the game database. This is certainly against REST principles - although perhaps that's mostly academic here. One of the biggest arguments against state-changing GET requests is that search engine crawlers, or humans who can be persuaded to click on links etc, will unexpectedly cause these state-changing actions - but given that the URLs for BGA player actions are not linked anywhere, and rely on particular query parameters as well as being dependent on game state and so on, it seems hugely unlikely that any incident could occur that ruins a game. Although not impossible - if I'm in a turn-based game and I want to cheat, and know an opponent will take a few days over their next turn, I could in theory figure out what the URL would be for some particular catastrophically stupid move they could in theory make, and do some social engineering attack to get them to trigger that link. Actually, does the server even check that there is a user making the request that matches the user ID in the URL? If not a cheat could "make moves" for their opponents all by themselves!
But I'm sure there are at least some session cookies or similar involved - at least I hope so!One other inconvenience of the GET request method is that it becomes hard to send structured data as part of a game action. In a POST request one could easily send a JSON body of arbitrary complexity. In theory a GET request could do the same by sending a JSON string as a query value - but this isn't' something that's really often done, and in any case wouldn't work in the BGA framework because the "action methods" only accept certain particular formats of data (for anti-cheating reasons, I suppose). I've already been struck with how awkward it is to send something simple like a list of card IDs to be discarded - you have to put all the IDs in a single comma-separated string, which admittedly isn't at all difficult but it becomes quite a bit of "boilerplate" to encode Javascript arrays this way on the client side then decode them to PHP arrays on the server side. And the complete inability to send more complex data like an array of objects (yes it could be done via JSON encoding/decoding but it feels like this would be discouraged, and you'd have to come up with your own validation on the server side to ensure the data is well-formed) also seems like a frustrating limitation.
Am I alone in feeling that this is all far from ideal? And are there good reasons it has to be this way, or is it just one of those historical accidents that came about and we're just now stuck with it because it would break too much to change it? (I expect it is, but I'd be interested to hear if there's more to the story.)
Thanks for indulging my question
and didn't fancy last night taking the extra clicks to see the page. I just did that now (of course https doesn't actually matter if you're just reading stuff!) and see the text is in English too. But I don't know why the 2 different URLs for the same docs in the same language, and if there are any actual differences in content.