В продолжении разговора о надежности, прочности и устойчивости. Недавно наткнулся на принцип, о существовании которого не знал, но много раз применял его на практике. Точней сказать, я не знал, что это целый принцип. 😃
Представляю вашему вниманию "Принцип прочности" (Robustness principle), он же "Закон Постела" (Postel's law). Джон Постел - один из основных соавторов современных сетевых протоколов. В ранней спецификации TCP он сформулировал этот принцип так:
Будь консервативен в своих действиях, но либерален к действиям других. Будь консервативен в том, что отправляешь, и либерален к тому, что принимаешь.
Давайте на примерах разберемся с условиями применимости данного принципа. Для себя я выделяю два случая, когда стоит присмотреться к подобному решению.
- Интеграция со сторонними системами. С одной стороны, вызывая внешний сервис, лучше четко следовать его спецификации. В случае отклонения от спецификации в лучшем случае можно получить ошибку, в худшем - неоднозначный результат. Например, если не передали значение какого-то атрибута, то внешний сервис может установить для этого атрибута значение по умолчанию или каким-то неочевидным образом изменить логику обработки запроса. С другой стороны, нет никакой надежды, что внешние сервисы будут пользоваться нашим, четко следуя нашей спецификации. В связи с этим можно смягчить требования к формату входящих запросов. Например, используя значения по умолчанию для отсутствующих атрибутов или игнорируя неизвестные атрибуты. Аналогично, вызывая внешний сервис и получая в ответе больше атрибутов, чем ожидалось, можно игнорировать всё ненужное.
- Расширение функциональности. Например, случай расширения модели данных. Очевидно, что клиенты, рассчитывающие на старую версию сервиса, не будут передавать новых значений. Также очевидно, что при переходе на новую версию системы без ее остановки в один момент времени будут существовать и старые, и новые клиенты. Если недостающие данные можно заполнить какими-то значениями по умолчанию, и это не приведет к негативным последствиям, такое решение может быть хорошим компромиссом, как минимум на время обновления системы.
Пожалуй, главный недостаток рассматриваемого подхода в том, что он может долго скрывать неблагонадежных участников взаимодействия. Если кто-то отклоняется от спецификации, а кто-то этому потворствует, умалчивая подобные факты, с течением времени может сформироваться целый пласт проблем. Критики также отмечают, что это также может приводить к проблемам безопасности в системе.
А как вы использовали этот подход в своей практике? Насколько этот опыт был позитивным или негативным?
***
P.s. Если вам интересна данная тематика, присоединяйтесь к моей новостной ленте в Telegram или здесь. Буду рад поделиться опытом. ;-)