Немного пятничного флуда:

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

Что такое "надежность в целом" вообще? Система почти наверное станет удобнее в интеграциях, но вполне возможно более уязвима к атакам и может быть несколько менее стабильна

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

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

че-то не гуглится этот закон

ну я к тому, что есть же разные аспекты, каждый из которых можно назвать "надёжность в чём-то". Суммировать их - средняя температура по больнице получится.
Про поддержку - а чёрт его знает. С одной стороны, меньше инцидентов вида "система отбила сообщение, потому что там лишний пробел затесался", с другой - больше инцидентов вида "что-то криво попарсилось и привело к неожиданному эффекту в логике". Второе можно компенсировать, действительно, более тщательной разработкой.

Наверное я бы даже сказал, что нестрогость валидации более хороша для разрабатываемых "один раз и нормально" систем, чем для постоянно допиливаемых

Судя по всему, вот этот

https://en.wikipedia.org/wiki/Robustness_principle

Ну вопрос не в "убрать" а сделать их более "умными". пусть например  у нас по формату название атрибутов в camel Case, а кто-то присылает в uppercase. Можно же и принять такое сообщение и корректно обработать (просто больше логики в принятии).

а, Постела а не Пастела

вот примерно про такую адаптивность к входным данным я и говорю : )

спасибо, благодаря этому я нашел интересный источник -Законы, теории, принципы и паттерны

Вообще это интересно ссылаться на Постела говоря о "системе"
Be conservative in what you send, be liberal in what you accept - кажется в "системе" не все соблюдают закон Постела если приходится обрабатывать кривые запросы ))

Ещё как я посмотрю с ним в комплекте едет и критика этого замечательного постулата, так что слепая отсылка как к buzzword - ну такое

Стремно как-то обобщать на целые системы, придумывался для протокола TCP. Плюс критика из вики: Martin Thomson argues that Postel's robustness principle actually leads to a lack of robustness, including security:[5]

Наверно, зависит от системы.

Если нужно сделать маркетплейс, обеспечить максимальную толерантность к пользователю, то нужно минимум полей валидировать в профиле пользователя.

Если речь идёт об обработке финансовых документов, то это совсем другая история.

Можно вообще ничего не валидировать, принимать бинари или длинные строки, разбирать, всё что не получилось разобрать, отправлять обратно.

Зависит от многих факторов. И да, не всегда, но часто нужно быть толерантным к принимаемым данным, потому что иногда клиенты (смежные системы) могут передавать только то, что могут. Иногда криво, и нужно быть готовым к тому, что не получится все запросы принять, уметь разрешать такие ситуации.

Например, когда смежные системы - древние, поросшие мхом. Ну не могут они по-другому, могут только в csv с кривыми данными.

У нас постоянно возникает подобная дилемма.
На месте решается тем, что аналитик/архитектор собирает заинтересованные стороны:
- data quality team member
- storage specialists
- business customers / business area experts

fight мусор в дб vs удобство

Обсуждается вопрос кому и что надо.
Вопрос закрывается.
Вот такие сходки возникают раз в 6-12 месяцев.

В платёжных системах всё намного жёстче и регламентируется законами

В платёжных системах по факту действует другой принцип: всё, что присылают пс, должно приниматься участниками пс несмотря на (не)соответствие форматам, протоколам и правилам пс.

Делал много интеграций с разнообразными платежными системами. Судя по тому, как там реализован API, там архитектор даже мимо не проходил :)

Иногда есть ощущение, что архитектор - это такой мифический зверь. Все о нем говорят - но мало кто видел. И даже если одного-двух таких заманят - никаких гарантий что наимплементят как они задумали. А жаль. Парни часто дело говорят и сквозь хрустальный шар видят будущее.