I agree with the author re: returning success on retries; it lets you automate the retry process. I work in mobile games; because someone might play in a tunne

I agree with the author re: returning success on retries; it lets you automate the retry process. I work in mobile games; because someone might play in a tunnel or bad network area, I need to make sure that every request is retry-able. To do that I generally include a GUID of some kind in the request; if the client says "create an entry for XXYY," there's a chance that the request will get to the server but the response will fail to reach the client. If the client is able to retry the request (with the same GUID) and get a success response, then I can have the retries handled transparently in the communication layer; all the client code needs to know is "I made this request and it was a success," without any knowledge of how many tries it took. If the second/third/etc request returned an error of some kind, I wouldn't have a good "success" response to hand back to the game code. (I'm assuming the "success" response contains some information that the game code needs.)