Здравствуйте, Sinclair, Вы писали:

S>·>Где есть два вида? В спеке?
S>Да, прямо в спеке.
Именно. А толку? Никакой безопасности это само по себе не обеспечит. В проде у тебя работает код, а не спека. Cпека ничего не может гарантировать о реализации.

S>·>Как конкретно это гарантируется? Только не говори: "в API нету!". Не слыхал историй, когда какие-нибудь rest-endpoints случайно возвращали json с неожиданными полями. All tests passed, всё у всех работает.
S>Я вроде написал, как. Историй про то, как all tests passed, а результат не соответствует — нет, не слышал.
Ну лень гуглить, но периодически выскакивают истории типа как из сайтов авиакомпаний и продаж билетов выковыривают инфу о том кто куда летает и где живёт.

S>Но вы отклоняетесь: если у вас такие кривые тесты, которые пропускают наличие лишних полей, то в системе с "привилегией на атрибуты" у вас тем более будет бардак.
Очередная иллюзия у тебя. Даже если в тесте не выдаётся лишних полей, это не значит что они не выдаются.

S>·>Ну о чём и говорю. "Спроектировал" — это написал тонну word-документов и презентаций.
S>Нет конечно. "Спроектировал" — это построил фреймворк, в котором не так много возможностей накосячить. Архитектура софта не исчерпывается "внешними" требованиями.
Гы. Очередной фреймворк-всемогутер.

S>·>И проверить легко, не спорю. А на самом деле json генерится питонячим кодом, который рефлексией вываливает всё что есть.
S>Вот это ваше "На самом деле" означает, что вы пытаетесь тестировать код как чёрный ящик. Это не единственный (и не самый эффективный) способ обеспечения качества.
S>Надо смотреть внутрь, и желающих генерить всё что есть через рефлексию бить палкой на code review.
Именно. Т.е. твой "правильный API" — это каша из топора. Начал ты "нарисуем границы API — и всё безопасно", а оказывается ещё надо досыпать тестирование, ящики разных цветов, палки и review.

Ещё раз повторю мой тезис: дизайн API — это в первую очередь про то как обеспечить взаимодействие систем удобным для человеков и эффективным для железяк способом. Поэтому твой 3й способ

Автор: Sinclair
Дата: 08.04.25

с ссылками никуда не годится, только снижает эффективность взаимодейсвтвия, а твоё "Зато всё безопасно" — чистая иллюзия.

S>·>И то никакой гарантии, что кто-то куда-то по ошибке не скопипастит.
S>Гарантия предотвращения ошибочных копипастов достигается юнит-тестированием.
Хорошо, но уже лучше. Осталось раскрыть а причём тут вообще "API устроен именно так".

S>Преимущество тут в том, что в коде нет ветвлений — поэтому нам не надо беспокоиться, что "вдруг" в результате образуется сontragent: {homeAddress: {...}}. Достаточно 1 (одного) теста на то, что такого в json нету, и вопрос закрыт.
Тут ведь как. Либо где-то будут ветвления, либо 1024 копипасты, в которой хрен разберёшься.

S>·>В серьёзных случаях у тебя будет 1024 вида своих и чужих.
S>Это как раз в несерьёзных случаях. Серьёзные случаи — это как раз какой-нибудь банковский API. И вот там всё именно так, как я сказал. Потому что нельзя позволить ни криворукому девелоперу нечаянно проверить не ту привилегию, так и криворукому админу нечаянно выдать кому-то не ту привилегию.
Я как раз такое и видел в банковском API. Когда есть какие-то таблицы роутингов и пермишеннов. Настолько огромные, что их никто толком проверить не может. В итоге эти таблицы либо копипастятся на авось, либо генерятся скриптами, с ветвлениями. Зато статичное и проверяемое (правда в теории только).

S>·>Что значит "вынести"? Попробуй хоть как-нибудь не "вынести" какой-нибудь оракл из твоего питоячего сервиса.
S>Ну вот так и не выносим. Оракл является подробностью реализации этого "питонячьего сервиса" и ниоткуда больше не виден. Впрочем, это может быть и не оракл — "питонячьему сервису" с запасом может хватить sqlite.
Он виден с т.з. анализа безопасности.

S>·>Если у тебя два сценария, то, конечно, это щастье. А вот когда сценариев 1024...
S>Когда у вас 1024 сценария, то деваться некуда. Но чаще это означает, что кто-то не справился с факторизацией сценария, в котором есть 8 отдельных подсценариев, каждый из которых работает независимо и его можно протестировать отдельно, т.к. там вариантов гораздо меньше.
Ты почему-то с больной головы на здоровую стал перекладывать. 1024 виртуальных ресурса предложил ты, так что 1024 сценария это у вас. А я как раз писал: "Каждую комбинацию тестировать не нужно. Нужно тестировать каждую привелегию." С чем ты тут же стал спорить. Ты уж определись.

S>·>Ну будет у тебя 1024 кусков кода и неподдерживаемая кодовая база.
S>И какая альтернатива?
Написал же неделю назад: "Каждую комбинацию тестировать не нужно".

S>Прекрасно. Видна некоторая попытка факторизации. Которая, к слову, совершенно бесполезна в вашем подходе с чёрным ящиком: а вдруг завтра кто-то заменит всю вашу кунсткамеру на "питонячий код, который по рефлексии вываливает сразу всё"?
Про тестирование чёрного ящика ты придумал сам, сам и спорь.

S>Ну, и вредна конечно тоже: потому что завтра кто-то в эксплуатации не нарулит кому-то такой набор привилегий, который не даёт выполнить реальный сценарий. Зачем так делать — непонятно. Ну, кроме "нам было лень проектировать, и мы свалили ответственность на кого-то другого.
Не очень понял проблему. Если реальный сценарий не ложится на привилегии — это ошбика бизнес-требований.