Post #335

Из перечисленных выше законов хочу обратить внимание на принцип Постела или Принцип устойчивости (Robustness principle). Изначально его сформулировал Джон Постел, разработчик множества интернет-протоколов. Многих учёных и инженеров называют "отцами" и "матерями" Интернета, а Постела ещё при жизни звали "God of the Internet", хотя он сам был против такого именования. Принцип устойчивости впервые приведен в RFC 760 со скромным названием "Internet Protocol". Позже переформулирован в RFC 1122: "Требования к хостам Internet". То есть, принцип изначально относится к приему и отправке IP-пакетов, и звучит так: Программы должны уметь обрабатывать все мыслимые ошибки; не имеет значения вероятность возникновения той или иной ошибки - раньше или позже пакет с любой возможной комбинацией ошибок и/или атрибутов будет получен и программа должна быть готова к обработке такого пакета.Если программа не может эффективно обрабатывать ошибки, она приведет прямой дорогой к хаосу.В общем случае лучше предположить, что сеть наводнена зловредными объектами, которые постоянно передают пакеты, предназначенные для нанесения максимального вреда. Такое предположение обеспечит высокий уровень защиты.Наиболее серьезные проблемы в Internet связаны с неисследованными механизмами, включающимися с малой вероятностью; намерения обычных злоумышленников никогда не могут принести такого вреда! На всех уровнях программ хостов Internet должны быть реализованы средства адаптации.Если спецификация протокола предполагает четыре возможных кода ошибки, приложение должно уметь обрабатывать по крайней мере пять типов ошибок (4 заданных и все остальные).Появление не определенных в спецификации кодов должно протоколироваться, но не должно нарушать работу системы. Всё это так же справедливо и на прикладном уровне, то есть в API. Особенно если вы проектируете открытые API или API микросервисов. Либерализм в том, что ваше API принимает на вход, позволяет развивать API, не создавая излишней связности между сервисом и его клиентами. Вот хорошая статья с примерами. В этом есть некоторое противоречие: когда вам рассказывают про API, обязательно говорят про схемы запросов и ответов (json-schema, xsd, схема в OpenAPI), и эти схемы исподволь продвигают идею контроля: больше правил валидации, точное указание типов данных и набора полей. Одновременно схема используется для генерации кода на клиентах и сервере. Удобно, если вы можете менять клиентов и сервер одновременно. Но это и означает связанность и синхронизацию релизов! Так можно делать, если: 1) ваше API внутреннее; И/ИЛИ 2) стабильность вашего сервиса важнее удобства клиентов (вы намного главнее и не зависите от клиентов - например, вы гос.орган, под который все подстроятся) А вот расшивка клиентов и сервера требует сооблюдения принципа устойчивости. Для API это означает, что схема запросов должна: 🔸допускать в запросах неизвестные поля и параметры (сервер должен игнорировать их и не выдавать ошибку); 🔸принимать значения в виде строк, а не чисел/булевых; 🔸не ограничивать значения набором символов, масками и регулярными выражениями; 🔸избегать перечислимых типов (enum); 🔸не ограничивать максимальный размер списков; Это не означает, что вообще не нужно делать никакие проверки — это означает, что не следует отправлять ошибку сразу при проверке запроса, до обработки. То есть, приняли, как есть, попытались обработать, всё, что не соответствует ожидаемому формату — записали в журнал. Проверки делаем не на уровне API, а немного за ним, поближе к логике: форматы и валидацию делаем там, а заодно санитарную обработку запроса — удаляем разные варианты инъекций, XML-бомб и т.п. И никогда не передавать/принимать напрямую бизнес-объекты без валидации и проверок! То же касается и клиента, которых должен уметь обрабатывать ответ сервера и не рушиться, несмотря на лишние поля и "неправильные" типы данных. Это позволит не синхронизировать обновления клиентов и сервера, и жить в период рассинхронизации — когда изменения не доехали или откатились.