Здравствуйте, Ночной Смотрящий, Вы писали:

P>>Ровно наоборот. Рест — принцип, архитектурный стиль.

НС>И один из ключевых принципов этого стиля — по максимуму использовать существующие абстракции HTTP. Ты же тут пропагандируешь прямо противоположное.

Так он был определен. Тем не менее, все теории развиваются, т.к. они и сами меняют реальность, и сами меняются вслед за изменениями реальности. РЕСТ ничем не лучше. Как только в широком доступе стало больше одного протокола, рест подход распространился и на них. нет никакой проблемы сделать ровно то же и на graphql, и на grpc, и вебсокетах, итд итд.

P>>Вы изобрели способ вытолкнуть бизнес-логику в инфраструктуру.

НС>Это вопрос выбора точки зрения, является ли идемпотентность частью бизнес-логики или нет.

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

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