🤔 Мысли об устойчивости и интерпретациях этого понятия

Много лет назад применительно к разработке сетевых протоколов был сформулирован принцип устойчивости (robustness principle), известный как закон Постела (Postel's law). Его формулировка: "Будь консервативен в том, что делаешь, и либерален в том, что принимаешь от других".

Если применить этот принцип к построению интеграционных взаимодействий, то можно сказать, что при отправке данных стоит строго соблюдать все стандарты, соглашения и схемы данных, чтобы не обманывать ожиданий, обеспечить совместимость и предсказуемое поведение участников взаимодействия.

На стороне получателя же это можно трактовать так, что надо подходить гибче, игнорировать незначительные нарушения и предусматривать план "Б", не "падая" по пустякам. Какие это могут быть действия (моя версия):

💡 Игнорировать неизвестные (дополнительно появившиеся) поля, свойства, параметры. Причина их появления может быть самой разной, в том числе развитие схемы API.
💡 Использовать, где это возможно по смыслу, разумные умолчательные значения и типы данных, допускающие неопределённое значение (nullable).
💡 Обрабатывать отсутствие некритических для сценария значений (иллюстрация на примере скрытия кнопки в GUI здесь).
💡 Применять схемы проверок данных, игнорируя незначительные ошибки, не влияющие на семантику (например, лишние пробелы, неверный регистр символов, отличный от ожиданий формат даты-времени).
💡 Быть готовым принимать иные, но совместимые типы данных, например, когда числовые и булевы значения поступают в форме строк.
💡 Не закладываться на порядок следования ключей в объектах JSON, даже если в примерах ваши смежники всегда выдерживают один и тот же порядок.
💡 Если это несущественно, игнорировать вложенность полей (скажем, если поставщик данных практикует частую модификацию структуры, а вам требуется по ID найти небольшое число полей).
💡 Стараться мягко обрабатывать неопределённости, когда поступают неполные и/или противоречивые данные (например, восстановление состояния по доступным данным, запрос недостающих данных, организация переспросов клиента).
💡 По возможности предусматривать обобщённую логику обработки при отсутствии обязательных параметров (например, если нельзя ответить конкретному клиенту специфически, поскольку в запросе не был передан его идентификатор, то можно ответить более общо на ту же тему).
💡 Предвидеть возможные нарушения хронологии при асинхронном взаимодействии (условно, логически второе событие может поступить раньше первого) и дублирующие/повторные данные.

Наверняка, список можно продолжить, но я остановлюсь на этом.

Что ещё ☝️
Поскольку списка официальных и авторитетных рекомендаций нет, то практика применения принципа устойчивости складывается по принципу: "Я художник, я так вижу". В частности, мне довелось несколько раз столкнуться с мнением, что намеренная передача внутри JSON различных типов в форме строк (например, вместо true нужно "true") — это тоже следование принципу устойчивости.

На это я хочу возразить: передача чисел и булевых данных в виде строк сама по себе не может считаться соблюдением закона Постела, поскольку нарушается правило консервативной (!) отправки (в стандарте JSON типы данных введены не для того, чтобы кто-то их оборачивал кавычками, сводя всё к строкам). А вот готовность обработать такое "чудо" на принимающей стороне — это уже хорошо и правильно, это повышает устойчивость решения.

#проектирование #интеграции