Что можно изменить частично:

data.account.hero.pvp можно вынести в отдельный метод. Я думаю, pvp интересует не очень большую часть игроков (кстати, можно же собрать статистику?). Альтернативный вариант - не добавлять информацию о pvp если герой не участвует в pvp.
data.account.hero.bag, data.account.hero.euqipment - можно оставить только переменные, а словарную информацию запрашивать отдельным методом (и кешировать на клиенте).
data.account.hero.diary, data.account.hero.messages - просто напрашивается вывод информации начиная с указанного в параметре момента времени
data.account.hero.quests - тут красивого решения предложить не могу. Но тоже очень больший кусок...

По поводу частичного получения информации. Если все делать параметрами, получится очень много. Почему бы не сделать язык запросов?

Так, запрос { "data": { "account": { "hero": { "energy": "?", "diary": { "?later": 1422696170.749529 } } } } } мог бы означать, что в ответе должны присутствовать разделы data.account.hero.energy и data.account.hero.diary, причем в дневнике нас интересуют только записи после 1422696170.749529.

Tiendil

Варианты:
1. рринимать параметром запроса список исключаемой информации (например, список квестов, список карт);
2. возвращать только изменение информации с момента предыдущего ответа;
3. отдельный «уменьшенный ответ» с самой важной информацией + маркер того, что изменился «большой» ответ;
4. ещё что-то.

CrazyNiger

Нет, второй вариант - вобще не вариант. Как же REST и все такое =)
Можно первый вариант, но наоборот. Добавлять параметр - какую информацию хочет получить клиент, если параметра нет, то всю.

Согласен: можно либо разбить /game/api/info на несколько запросов - основная информация, квесты, рюкзак и т. п., либо добавить параметр к этому запросу с желаемыми блоками информации. При отсутствии параметра возвращать всю информацию. "Уменьшенный ответ" можно сделать тем же запросом с особым параметром - например, та же "основная информация".

mayorovp

data.account.hero.bag, data.account.hero.euqipment - можно оставить только переменные, а словарную информацию запрашивать отдельным методом (и кешировать на клиенте).

Что имеется ввиду под "переменными" и под "словарной информацией"?

data.account.hero.diary, data.account.hero.messages - просто напрашивается вывод информации начиная с указанного в параметре момента времени

Так, как сейчас, мне кажется, вполне нормально, не нужно городить к этому дополнительные параметры.

data.account.hero.quests - тут красивого решения предложить не могу. Но тоже очень больший кусок...

Опять же, сам по себе этот параметр в ответе не такой уж и большой, если он будет отдельно.

По поводу частичного получения информации. Если все делать параметрами, получится очень много. Почему бы не сделать язык запросов?
Так, запрос { "data": { "account": { "hero": { "energy": "?", "diary": { "?later": 1422696170.749529 } } } } } мог бы означать, что в ответе должны присутствовать разделы data.account.hero.energy и data.account.hero.diary, причем в дневнике нас интересуют только записи после 1422696170.749529.

Ненужное усложнение, имхо. Параметра со списком желаемых блоков будет достаточно.

Hamster

Что имеется ввиду под "переменными" и под "словарной информацией"?

К примеру, название предмета однозначно определяется исходя из его номера - нет необходимости передавать его в каждом ответе.

mayorovp

К примеру, название предмета однозначно определяется исходя из его номера - нет необходимости передавать его в каждом ответе.

Мне кажется, на таких уж спичках экономить не надо)

Почему это вдруг спички? Перечисленные мною "спички" в сумме половину трафика составляют.

Потому что я говорил о названиях предметов, а не обо всех твоих пунктах.

Названия предметов тоже прилично места отнимают.

Кстати да, где-то килобайт будет с названий. Можно оставить это на стороне клиента - одни эти "спички" неплохо сэкономят. С другой стороны, разработчикам каждый раз придется вручную обновлять базы названий при обновлении Сказки, что не есть гуд.

Зачем вручную? Говорю же, запрашивать справочные данные отдельным методом и кешировать их на клиенте.

А почему тогда не поменять ключи с data.account.hero.euqipment на, например, d.a.h.e ? Тоже много сэкономится.

Это резко снизит читаемость ответа. А если плевать на читаемость - то надо переходить на бинарный протокол сразу, без промежуточного json с однобуквенными ключами.

mayorovp

Это резко снизит читаемость ответа. А если плевать на читаемость - то надо переходить на бинарный протокол сразу, без промежуточного json с однобуквенными ключами.

Так читать-то его никому и не надо.
Ну да, можно и на бинарный. И гзипом его.

В общем, мое мнение таково: сначала нужно сделать минимум изменений - то есть, разбить большой запрос на много маленьких (либо, что по сути то же самое, добавить параметры, какие блоки нужны), внутренности можно и не переделывать так кардинально. А уже потом можно думать о кардинальных изменениях, если таковые потребуются - хоть бинарный формат. Но, мне кажется, это уже не будет необходимо.

Зачем вручную? Говорю же, запрашивать справочные данные отдельным методом и кешировать их на клиенте.

Тогда это означает кнопку в клиенте "когда Сказка обновится, нажми сюда". Ибо запрашивать их периодически - еще больше увеличивать потребление трафика, а давать знать клиенту, что именно сейчас следует обновить базы, кроме какого-либо exception handling'а, когда нарываешься на незнакомый объект, я не знаю.

Silent Wrangler
Требуемый номер версии справочников можно в том же /api/info или /game/api/info передавать. Одно число - не 20 строк.

Логично.
Кстати, тогда так можно и с городами и именами советников. Если отставание клиента не больше N версий, то передается только дельта за N (список изменений на стороне сервера) версий, если больше - весь справочник.
Версию своего справочника посылает клиент, на сервере сличают с актуальной. Плюс пара миллисекунд на запрос погоды не сделает.