Получение ответа и успех операции являются разными событиями
Сбой транспорта означает проблему при обмене данными: например, соединение не удалось установить или ответ не удалось получить. HTTP-статус появляется, когда сервер уже сообщает результат обработки запроса. Поэтому отсутствие транспортной ошибки не доказывает успешность операции. В приложениях на Swift при использовании URLSession нужно отдельно учитывать ошибку обмена и статус HTTPURLResponse. Коды из диапазона успешных ответов проверяют согласно договорённости конкретного API. Код 404 нельзя просто превратить в пустой список: он может означать, что запрошенный ресурс не найден. Пользователю важно различать отсутствие элементов и невозможность получить нужную информацию. Внутри программы эти состояния тоже должны оставаться разными.
Содержимое проверяют после статуса
Даже успешный HTTP-ответ может не соответствовать тому, что ожидает экран. Вместо массива объектов пришёл объект другой формы, обязательное поле отсутствует или число представлено иначе. Декодирование переводит полученные данные в модель приложения, но для этого нужна согласованная структура. Полезно иметь отдельный этап проверки и преобразования ответа. Он не должен незаметно заменять любые ошибки вымышленными значениями. Если возраст неизвестен, ноль не обязательно является корректной подстановкой. Тестовые примеры помогают заранее увидеть такие случаи: пустой корректный ответ, ответ с пропущенным полем и явно неподходящее содержимое. Для журналов диагностики выбирают только необходимые сведения, исключая токены доступа и личные данные.
Повтор и отмена требуют понятных правил
При временном сбое чтения повтор иногда уместен, но бесконечная отправка запросов ухудшает ситуацию. Особенно осторожно обращаются с операциями создания или изменения данных. Если сервер успел создать запись, а ответ потерялся, слепой повтор может создать дубль. Возможность безопасного повтора определяется договорённостью API, а не только желанием убрать сообщение об ошибке. Отмена запроса также является самостоятельным исходом. Когда пользователь ушёл с экрана, запоздавший ответ не должен неожиданно подменять данные нового экрана. Нужно учитывать, к какому действию относится результат. При этом отмену на клиенте нельзя воспринимать как универсальное доказательство отмены уже выполненного серверного изменения. Для неоднозначного исхода сначала выясняют состояние операции предусмотренным способом.
Попробуйте на практике
Спроектируйте обработку загрузки списка на бумаге, не обращаясь к реальному серверу.
- Опишите четыре состояния экрана: загрузка, полученные данные, корректный пустой список и ошибка. Укажите, что пользователь увидит в каждом.
- Подготовьте три вымышленных исхода: сбой соединения, HTTP-ответ 404 и успешный статус с неподходящей структурой данных. Назовите уровень каждой проблемы.
- Добавьте сценарий ухода с экрана до завершения запроса. Опишите, как отличить устаревший результат от актуального.
- Отдельно рассмотрите создание записи с потерянным ответом. Укажите, какую проверку состояния нужно выполнить до возможного повтора.
Как проверить результат. Три уровня ошибок различаются, пустой список не скрывает сбой, а повтор изменяющего запроса не выполняется автоматически без понимания его последствий. В плане отсутствует запись секретов в диагностический журнал.
Частые вопросы
Код 200 гарантирует правильность всех данных?
Нет. Он сообщает HTTP-результат, но не заменяет проверку структуры и смысла содержимого по условиям API.
Можно ли всегда показать одно сообщение о проблеме сети?
Такое упрощение скрывает различия. Ошибка сервера или структуры ответа может возникнуть при работающем соединении. Сообщение должно помогать понять допустимый следующий шаг.
Самостоятельный разбор темы. Содержание конкретной обучающей программы здесь не представлено.