Ответ мог потеряться после принятия заявки
Клиент отправляет запрос, сервер обрабатывает его, затем возвращает ответ. Нарушение связи возможно на разных участках этого пути. Поэтому одинаковое сообщение о сетевой ошибке совместимо с разными исходами: запрос мог не дойти, а мог быть принят до разрыва соединения. Это означает, что повторное нажатие с созданием нового поручения нельзя считать безобидным восстановлением экрана. Если первое поручение уже принято, второе способно оказаться самостоятельной заявкой. В учебной модели неизвестный исход следует обозначать именно как неизвестный, пока не получены сведения о конкретной операции.
Идентификатор связывает наблюдения об одной операции
В клиенте полезно сохранять идентификатор запроса до отправки и связывать с ним последующие ответы. При работе с интерфейсом брокера важно различать идентификатор запроса и идентификатор, присвоенный заявке другой стороной. Способ поиска состояния зависит от поддерживаемого типа идентификатора. Механизм идемпотентности помогает ограничивать повторное создание одной операции, но работает по правилам конкретного интерфейса. У него могут быть условия и сроки действия. Из самого слова идемпотентность нельзя вывести, что любой повтор безопасен бесконечно или всегда возвращает ответ одного формата. Эти свойства проверяют в актуальной документации, а не предполагают по названию.
Принятая заявка ещё не означает полное исполнение
Даже после получения подтверждения остаётся вопрос, что именно подтверждено. Принятие, частичное исполнение и окончательное состояние описывают разные события. Сетевой тайм-аут не заменяет ни одного из них. Например, в вымышленном журнале заявка на десять единиц принята, а позже подтверждено исполнение трёх. Нельзя показывать десять исполненных единиц только потому, что сервер ответил успешно. Нельзя и стирать уже подтверждённые три из-за следующего сбоя связи. Экран должен опираться на известные события и отдельно отмечать, какая часть состояния ещё требует уточнения. Это разбор надёжности программы, а не рекомендация совершать сделки.
Попробуйте на практике
Составьте бумажный журнал вымышленной заявки. Не подключайтесь к брокеру и не отправляйте реальные поручения.
- Запишите условную заявку на десять единиц и присвойте ей учебный идентификатор. Отметьте время отправки без утверждения, что сервер её принял.
- Добавьте событие: соединение оборвалось до получения ответа. Напишите корректный статус интерфейса, сохраняющий неопределённость исхода.
- Добавьте результат последующего чтения состояния: заявка принята, исполнены три единицы. Разделите подтверждённый факт и оставшуюся неопределённость.
- Рассмотрите предложение отправить такую же заявку с новым идентификатором. Опишите возможный дубль и укажите, какие сведения нужно сверить до решения о следующем действии.
Как проверить результат. Проверка пройдена, если сетевой сбой нигде не назван доказанной отменой, три исполненные единицы не превратились в десять, а новый идентификатор не объявлен безопасным продолжением старой операции.
Частые вопросы
Почему недостаточно просто повторить запрос?
Потому что исход первого запроса может быть неизвестен. Для корректного восстановления нужны связь с исходной операцией, чтение её состояния и соблюдение правил конкретного интерфейса.
Можно ли убрать неизвестный статус ради удобства пользователя?
Лучше ясно объяснить, что подтверждено и что уточняется. Уверенная, но неподтверждённая надпись может подтолкнуть человека к действию на неверном основании.
Самостоятельный разбор темы. Содержание конкретной обучающей программы здесь не представлено.