Клиент ↔ сервер. Давайте не ссориться
Все проблемы взаимодействия серверных и мобильных разработчиков можно условно разделить на две категории: проблемы машинные и проблемы человеческие.
Среди неурядиц первого рода наиболее распространены проблемы, связанные с парсингом объектов, отсутствием необходимой информации в ответе сервера и обработкой push нотификаций.
Нередки ситуации, когда одни и те же объекты в ответах на разные запросы имеют различную структуру, названия полей или формат данных. Это вынуждает программистов клиентского приложения отказываться от использования библиотек, автоматизирующих рутинные операции, и обрабатывать каждый response вручную. В результате получаем неоправданно утяжеленный, порой едва читабельный из-за многочисленных заплаток и костылей код, увеличенное время разработки и отладки, затруднения при поддержке готового приложения и благодатную почву для будущих ошибок.
Отсутствие необходимой информации в ответе сервера также доставляет немало хлопот программистам, работающим над клиентским приложением. Так, например, формируя ответ на запрос редактирования данных, backend разработчики не всегда включают в него измененный объект. Подобные решения вынуждают мобильное приложение посылать дополнительный запрос на сервер или пытаться самостоятельно актуализировать состояние объекта, рискуя спровоцировать рассинхронизацию данных на сервере и устройстве.
Особенно критичной нехватка данных в response представляется при обработке ошибок. Недостаток или неточность информации о причинах, вызвавших сбой, лишает возможности показать пользователю релевантное сообщение и скорректировать его действия.
Несмотря на широкое распространение push нотификаций, их обработка часто вызывает проблемы у backend программистов. Порой учетной записи пользователя ставится в соответствие только один токен устройства, а не массив токенов. При этом, если приложение запущено на нескольких девайсах, push уведомления получает только устройство, где вход в систему был осуществлен последним. Другой распространенной ошибкой является хранение токена даже после того, как на устройстве была произведена смена аккаунта. В таком случае пользователи будут получать чужие нотификации.
Что же касается проблем человеческих чаще всего они связаны с несистематизированной, запутанной или неполной документацией, а иногда и с полным отсутствием её. В ситуации, когда мобильная и серверная разработка ведутся параллельно, важно также поддерживать документацию в актуальном состоянии и своевременно сообщать о вносимых в API изменениях. Пытаясь опытным путем нащупать единственно верный способ взаимодействия с сервером, мобильный разработчик вынужден тратить большое количество времени на реализацию даже самых простых функций, что часто кажется заказчикам неприемлемым. Поэтому недооценивать роль грамотно составленной и систематически актуализируемой API документации весьма неразумно.
Избежать описанных выше казусов на самом деле несложно. Достаточно просто помнить, что плодами ваших трудов будут пользоваться другие члены команды и во многом именно от ваших усилий зависит результат их работы.