ETag и If Match при изменении конфигурации узла
Два специалиста одновременно открыли настройки полевого шлюза. Один изменил период отчётов, другой позже сохранил свой старый экран и незаметно затёр первое изменение. Для HTTP интерфейса можно проверить поддерживаемую условную запись, но её наличие и смысл должны подтверждаться контрактом конкретного сервиса конфигурации.
Определить защищаемое представление
RFC9110 описывает валидаторы представления и условие If-Match. (IETF — RFC9110 HTTP Semantics) Выясните, выдаёт ли API подходящий ETag и к какой конфигурации он относится. Отметка версии HTML страницы не обязательно является валидатором настроек устройства. Нужен документированный ресурс с понятной областью изменения.
Уточните метод сохранения и требования сервера к условным запросам. Самостоятельно добавленный заголовок не создаёт защиты, если сервис его не проверяет. Приложение должно различать успешное обновление и отказ из-за несоответствия предварительного условия, сохраняя причину для пользователя.
Выполнить опыт двух редакторов
На учебном узле получите одну исходную конфигурацию двумя независимыми клиентами. Первый сохраняет разрешённое безопасное изменение. Второй пытается записать своё представление с исходным валидатором. Ожидаемый результат согласуйте до опыта: устаревшая запись не должна молча затереть новое состояние.
Увеличить схему
После отказа повторно прочитайте актуальную конфигурацию. Сравните поля и покажите специалисту конфликт. Не превращайте обработку ошибки в автоматическую отправку без условия: это фактически отменяет проверку и возвращает исходную проблему потерянного обновления.
Разделить конфликт и применение на устройстве
Успешная условная запись в сервис ещё не доказывает, что удалённый шлюз уже применил настройки. Если конфигурация доставляется асинхронно, сохраняйте отдельные версии желаемого и фактического состояния. Согласованность двух редакторов и завершение доставки являются разными проверками.
Проверьте, что происходит при нескольких связанных ресурсах конфигурации. Валидатор одного представления не следует объявлять общей транзакцией всех настроек без явной поддержки API. Для составного изменения нужен соответствующий контракт либо понятная процедура последовательного применения.
Сохранить историю решения
В журнале записывайте исходную версию, результат условия и подтверждённую новую конфигурацию без секретов. Для конфликта должен существовать ответственный выбор, какие изменения совместимы и что требуется пересмотреть. Не выполняйте механическое объединение значений, если их смысл взаимозависим.
Приёмка включает параллельное редактирование и подтверждение фактического состояния узла. После изменения интерфейса повторите опыт. Для хозяйства результатом становится объяснимая история настройки, где позднее сохранение старого экрана обнаруживается как конфликт, а успешная доставка конфигурации имеет собственное проверяемое подтверждение.
