Если бекендер очень высокого уровня, то есть умеет красиво и оптимально проектировать методы и данные под потребности клиентских app, четко это документировать (swagger) и покрывать тестами свои методы, то обычно таких проблем не возникает.
В противном случае контролируйте все что приходит с бекенда, сделайте статические мапперы, подстраиваться под бек не вариант, всякие линтеры начнут ругаться, вы начнете запутыватся в плохоименованных переменных, уговаривать бекендеров слать данные в нужном формате то же больше времени потратите, третий вариант сам приемлемый, бекенд часто шлет, не то что в нужном формате а еще много того что не нужно на фронт.
Например: бекенд шлет (это частая ситуация, так в бд например хранится, а правила кодирования у разных клиентов (web, ios, android) свои, но они могут использовать один и тот же бек)
{
ID '2342',
stu_cfg: 'werwer'
pfu_num: '1231'
sys_created: '2000-12-10'
register_date: '06 Mar 2017 21:22:23 Z'
}
бы обозначаете что вам нужно и в каком виде (в тайпскипте например) (или в js комментариями)
interface SomeEntity {
id: string,
status: string,
created: Date
registered: Date
}
class MyMapper {
static someEntityToClient(data): SomeEntity {
const someEntity: SomeEntity = {
id = data['ID'],
status = data['stu_cfg'],
created = moment(data['sys_created']).toDate
registered = moment(data['register_date']).toDate
}
return someEntity;
}
}
И вызовите маппер сразу после апи вызова как только получили данные. Таким образом вы решите проблемы:
1) ненужные данные отфильтруете, чтоб не ломать голову (что это? зачем?) потом во время отладки фронта
2) в коде будет единый стандарт именования переменных (плюс закодированные имена (cfg, klk и т. п.) пропишете понятно).
3) в бизнес логике будет единый стандарт типов данных (как например со временем) (преобразований не надо потом нигде по 10 раз делать, проверки отпадут, вы все проконтролировали на входе)
