Александр Александров к сожалению, вынужден присоединиться к
Сергей в том, что вы не знаете, что вам нужно от сервера.
Понимаете, все эти архитектурные паттерны - "бэкенды" в web-понимании, REST-ы - это все хорошо и удобно, но стандартные подходы web - это не всегда про игры и риалтайм-приложения.
Вы должны принять много различных решений, прежде чем браться что-то делать.
> есть сервер, к которому обращается игровое приложение что бы записать или извлечь определенных данные игрока
Вот в этих "определенных данных" и вся суть. Можно по-разному распределять логику между клиентом и сервером, но нередко, особенно в играх, где нужна устойчивость к мошенничеству, большая часть игровой логики находится на сервере. Это гораздо больше, чем "извлечь данные игрока". Если игровая логика находится на сервере, то тогда и требования к процессу обмена данными соответствующие - в REST особого смысла нет, т.к. все равно придется вводить понятие "сессии" или "соединения" с сервером, и хранить его состояние. И ваша основная задача будет не в легкой масштабируемости на заранее неизвестное число клиентов, а наоборот, в поддержании максимально комфортного игрового процесса для имеющихся игроков, а масштабирование будет на втором месте и будет достигаться немного иными архитектурными решениями.
Многие крупные игровые проекты с большой долей логики на сервере используют свои протоколы обмена (как правило, бинарные) поверх обычного TCP-соединения. Многие применяют различные языки описания таких протоколов, чтобы было проще управлять разработкой, и вносить изменения в протокол (например, по таким описаниям можно автоматически генерировать часть серверного и клиентского кода). Например, Близзы, насколько мне известно, используют
Protocol Buffers для Diablo 3.
С другой стороны, если ваша игра - по сути однопользовательская (например, маджонг какой-нибудь), и вам нужно только сохранять статистику, без особых требований к доверию (т.е. только ради удобства игрока), то тогда простенький REST-сервис вам прекрасно подойдет.
возможность сохранить процесс прохождения игры
вам нужно решить, какой уровень доверия у этих данных. Это во многом и будет определять архитектуру. Если ваш проект соревновательного характера, и подмена данных о достижениях или подтасовка результатов отдельных игр или матчей может поставить крест на всем проекте, то тогда клиент не может быть доверенной стороной, и критичная логика должна быть на сервере.
