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

S>1 запрос — пароль1, пароль2. Ок, поменяли.
S>2 такой же запрос — пароль1, пароль2 — уже не пройдет, т.к. новый пароль — это пароль2 (был установлен на предыдущем шаге).

Будет ошибка, но состояние то сервиса не поменяется. Значит идемпотентность сохраняется и можно использовать PUT.

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

НС>И сразу получит 404. А теперь поясни — зачем тебе на клиенте понадобилось знать, удалил ли ты реально или все уже удалено?

Для информирования пользователя о том, чего он натворил, а чего без него успел кто-то понаделать.
Это не обязательное поведение и то и то допустимо, лишь бы человеки понимали особенности.

НС>Удаление по id это тоже удаление по условию, никакой разницы.

ну, при удалении людей старше 35 лет, метод вряд ли будет бросать 404, т.к. не указывалась конкретная запись.
Скорее всего, будет всегда кидать 200.

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

vsb>Почему бы первому DELETE не возвращать 200, а последующим 404? Вроде это ничему не противоречит. А то, что код возврата разный, ну и что.
vsb>Да и как вообще реализовать DELETE, который будет возвращать 200 на удалённый ресурс? Это из базы нельзя ничего удалять?

Soft-delete сделать какой-нибудь.

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

P>>На самом деле если абстрагироваться от хттп
НС>Абстрагироваться от хттп это прямо совсем не про REST, а здесь таки REST обсуждается.

Здесь мы обсуждаем http POST. REST как раз можно и без http применять.

НС>>>Неа. Бизнес-логика, это если ключ присутствует на бизнес-уровне. А вот если ключ специальный и ей ортогонален, то не нужно тащить его в бизнес-слой.
P>>А где и как ты собираешься проверять, повторный ли это реквест и в каком он состоянии?

НС>В мидлвере.

Неинтересно. Все равно протаскивать, проверять итд. Ну вот подломал ктото мидлвару или не подключил — всё, приплыли. А так будет явный вызов.

P>>Идемпотентность это свойство прежде всего бизнес-операции.

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

Копипастить и не нужно. Всё равно ведь придется в метаданных указать, что именно у нас идемпотентное.

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

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

НС>>Абстрагироваться от хттп это прямо совсем не про REST, а здесь таки REST обсуждается.
P>Здесь мы обсуждаем http POST.

Нет, именно REST.

НС>>В мидлвере.
P>Неинтересно. Все равно протаскивать, проверять итд. Ну вот подломал ктото мидлвару или не подключил — всё, приплыли.

Абалдеть логика. И часто у вас мидлвары подламывают или не подключают? А то, знаешь ли, та же аутентификация и авторизация тоже в виде мидлвар сделаны. Если такое можно подломать — не представляю как вы вообще разработку ведете.

P>>>Идемпотентность это свойство прежде всего бизнес-операции.
НС>>Однако обеспечение этой идемпотентности при помощи отдельного ключа — штука весьма универсальная, и не нужно ее копипастить в бизнес-коде по всем идемпотентным методам.
P>Копипастить и не нужно.

Нужно. Как минимум прописать это в модели, а потом из модели достать и куда то засунуть.

P> Всё равно ведь придется в метаданных указать, что именно у нас идемпотентное.

Для этого достаточно просто атрибут на метод навесить.

P>То есть, не совсем ясно, какие бенефиты вытаскивать такое в мидлвару

Универсальность и прозрачность. Ты же не таскаешь токен авторизации в модели, правда? Или таскаешь?

P>И отлаживать проще, и отслеживать,

Чем проще?

P> и смена транспорта не повлечет тотальное переписывание

Смена транспорта RESTful сервиса? Это какие то сказки. Если только на gRPC, но при этом отличия от HTTP будут минимальны.

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

НС>>>Абстрагироваться от хттп это прямо совсем не про REST, а здесь таки REST обсуждается.
P>>Здесь мы обсуждаем http POST.

НС>Нет, именно REST.

Смотри прямо заголовок — там POST, т.е. метод http. Если обсуждается именно Рест, то его надо обсуждать в отрыве от какого либо транспортного протокола.

P>>Неинтересно. Все равно протаскивать, проверять итд. Ну вот подломал ктото мидлвару или не подключил — всё, приплыли.

НС>Абалдеть логика. И часто у вас мидлвары подламывают или не подключают?

Похоже, щас ты скажешь, что у вас изобрели способ писать без багов.

> А то, знаешь ли, та же аутентификация и авторизация тоже в виде мидлвар сделаны. Если такое можно подломать — не представляю как вы вообще разработку ведете.

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

P>>Копипастить и не нужно.
НС>Нужно. Как минимум прописать это в модели, а потом из модели достать и куда то засунуть.

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

P>> Всё равно ведь придется в метаданных указать, что именно у нас идемпотентное.
НС>Для этого достаточно просто атрибут на метод навесить.

Спасибо Кэп, я именно это показал двумя постами назад.

P>>То есть, не совсем ясно, какие бенефиты вытаскивать такое в мидлвару
НС>Универсальность и прозрачность. Ты же не таскаешь токен авторизации в модели, правда? Или таскаешь?

Энвелоп у вас еще не изобрели?

P>>И отлаживать проще, и отслеживать,
НС>Чем проще?

Можно писать тесты ниже уровнем, дешевые, быстрые.

P>> и смена транспорта не повлечет тотальное переписывание

НС>Смена транспорта RESTful сервиса? Это какие то сказки. Если только на gRPC, но при этом отличия от HTTP будут минимальны.

Именно. Смена транспорта это вобщем норма на большом промежутке времени. Бывает и на grapql переходят, и на grpc, и на что угодно. Проще явно ввести этот энвелоп.
Все что можно вынести в мидлвару — синхронизацию поля в энвелопе со значением хидера для http, на случай если придется это как то учитывать в каком гатевее.

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

P>>То есть, не совсем ясно, какие бенефиты вытаскивать такое в мидлвару
НС>Универсальность и прозрачность. Ты же не таскаешь токен авторизации в модели, правда? Или таскаешь?

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

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

НС>>Нет, именно REST.
P>Смотри прямо заголовок — там POST, т.е. метод http.

Это серия постов от Шымжи, про REST. И по ссылке про REST. Поэтому все что я написал написано про REST, и попытки натянуть это на другие протоколы — скажем так, некорректны.

P>Если обсуждается именно Рест, то его надо обсуждать в отрыве от какого либо транспортного протокола.

REST в принципе не надо обсуждать в отрыве от протоколов, это противоречит его кулючевому принципу.

P>>>Неинтересно. Все равно протаскивать, проверять итд. Ну вот подломал ктото мидлвару или не подключил — всё, приплыли.
НС>>Абалдеть логика. И часто у вас мидлвары подламывают или не подключают?
P>Похоже, щас ты скажешь, что у вас изобрели способ писать без багов.

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

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

НС>REST в принципе не надо обсуждать в отрыве от протоколов, это противоречит его кулючевому принципу.

Ровно наоборот. Рест — принцип, архитектурный стиль. http — протокол, который хорошо подходит для restful систем.

НС>>>Абалдеть логика. И часто у вас мидлвары подламывают или не подключают?
P>>Похоже, щас ты скажешь, что у вас изобрели способ писать без багов.

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

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

Забавно, этим летом у меня был доклад про разработку фремворка и отношение к нему продуктовых разработчиков:

Product developer always request adding their business logic into your framework.

Собственно, ты в очередной раз подтвердил, что эта песня будет вечной.

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

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

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

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

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

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

S>Если мы уже дошли до вызова ф-ии из BL, значит с авторизацией вопрос решили, соотв. идемпотентность -- это требование к BL, отсюда явное присутствие этого параметра на этом уровне.

Не вижу логики, что это обязательно именно требование к BL. С т.з. именно бизнес-логики — в систему приходит заказ и он должен быть обработан. Заказ должен как-то корректно поступить в систему — и тут начинается логика обработки заказа.

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

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

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

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

S>>1 запрос — пароль1, пароль2. Ок, поменяли.
S>>2 такой же запрос — пароль1, пароль2 — уже не пройдет, т.к. новый пароль — это пароль2 (был установлен на предыдущем шаге).
НС>Будет ошибка, но состояние то сервиса не поменяется. Значит идемпотентность сохраняется и можно использовать PUT.
С т.з. безопасности такой подход — дыра. Несовпадение пароля должно трактоваться как неуспешная попытка аутентификации и инкремировать счётчик, блокируя аккаунт при переполнении. Иначе API смены пароля будут использовать для подбора паролей.
Полагаю, правильным подходом будет попробовать пароль2, если пароль1 не сработал и просто отвечать ОК если пароль2 подошел.

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

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

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

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

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

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

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

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

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

S>>Если мы уже дошли до вызова ф-ии из BL, значит с авторизацией вопрос решили, соотв. идемпотентность -- это требование к BL, отсюда явное присутствие этого параметра на этом уровне.

F>Не вижу логики, что это обязательно именно требование к BL.

Очень просто — средства на оплату конкретного заказа должны быть списаны ровно один раз вне зависимости от того, сколько попыток было оплатить.
Это БЛ. Все остальное есть просто реализация вот такого требования.

Причны скорее всего будут технического характера, но гарантии определяет бизнес операция — возможны ли дубликаты, или нет.

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

S>>>Если мы уже дошли до вызова ф-ии из BL, значит с авторизацией вопрос решили, соотв. идемпотентность -- это требование к BL, отсюда явное присутствие этого параметра на этом уровне.
F>>Не вижу логики, что это обязательно именно требование к BL.

P>Очень просто — средства на оплату конкретного заказа должны быть списаны ровно один раз вне зависимости от того, сколько попыток было оплатить.
P>Это БЛ. Все остальное есть просто реализация вот такого требования.

Это бизнес-требование, которое может быть реализовано как идемпотентной операцией, так и без всякой идемпотентности (например так, что первое обращение списывает деньги и меняет состояние заказа и возвращает чек, второе дает ошибку, меняет внутренний счетчик попыток оплаты, отсылает СМС, и возвращает ошибку — совсем неидемпотентная операция, которая, однако, закроет вот этот требование единичной оплаты).

Требования могут быть реализованы как часть бизнес-логики, так и в целом техническим стеком вне этой логики. Например, бизнесу так же может требования консистентное сохранение данных заказа, но я могу не реализовывать транзакционность вручную в бизнес-логике, а использовать СУБД, в которой эта поддержка уже есть.

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

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

Это основополагающий принцип. Если от него отказаться, это уже будет совсем не REST.

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

Нет. Ты RFC то читал? Там ясно прописана цель — обеспечить отсутствие дублей при ретраях. Это — не бизнес логика, это инфраструктурная логика для борьбы с ненадежностью канала передачи.
Я тебе больше скажу, при использовании решений типа istio эта логика с клиентской стороны вообще физически уезжает из бизнес-кода в отдельный инфраструктурный контейнер. Что характерно, как раз благодаря тому, что абстракции уровня HTTP в REST не игнорируются, и содержимое на уровне HTTP обладает достаточной семантикой чтобы обеспечить довольно сложные вещи типа кеширования или ретраев находясь на уровне HTTP и ничего не зная про бизнес-логику. Если же ты абстрагируешься от протокола, такие решения станут невозможными.

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

S>>Если мы уже дошли до вызова ф-ии из BL, значит с авторизацией вопрос решили, соотв. идемпотентность -- это требование к BL, отсюда явное присутствие этого параметра на этом уровне.
F>Не вижу логики, что это обязательно именно требование к BL. С т.з. именно бизнес-логики — в систему приходит заказ и он должен быть обработан. Заказ должен как-то корректно поступить в систему — и тут начинается логика обработки заказа.
F>И наоборот, логика проверки ключа идемпотентности может быть совершенно одинаковой как при заказе такси, так и при переключении канала трансляции на коммутаторе, хотя с т.з. бизнеса это совершенно разные бизнес-процессы из совершенно разных областей.
F>Идемпотентность операций при REST-запросах вполне можно трактовать как чисто техническое решение для технических проблем вида разрыва соединения, плохой связи и подобного, не имеющих прямого отношения к собственно логике бизнеса.
F>Хотя в каких-то случаях логика проверки дубликатов может быть важной частью бизнес-процесса, хотя скорее там будет описан не синтетический ключ идемпотентности, а какие-то правила сравнения по данным, которые позволяют считать разные сущности одинаковыми.

С тем что выше я спорить не буду. Но почему иногда, в отдельных случаях, важность идемпотентности для BL
не манифестировать на уровне типов, т.е. доп. параметр? Прям важно, чтобы клиент это осознавал, что не отменяет
возможность все это решать на уровне middleware.

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

S>С тем что выше я спорить не буду. Но почему иногда, в отдельных случаях, важность идемпотентности для BL
S>не манифестировать на уровне типов, т.е. доп. параметр? Прям важно, чтобы клиент это осознавал, что не отменяет
S>возможность все это решать на уровне middleware.

Когда надо — тогда стоит делать.

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

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

S>Минус очевидный — это диктует тип ключей — только UUID. А если хочется чтобы ключи генерила СУБД и там спец. система для распределенной генерации ключей? Т.е. такой PUT как бы обязывает применять новую схему создания ключей.

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

Однако можно сделать ключом крипто-хеш от содержимого записи, приведя ее сначала в вид, не зависящий от вариантов форматирования и порядка полей в объекте.

S>И если уж так подойти — то запросы POST вообще лишены смысла — ведь они не идемпотентны, а это плохо всегда, т.к. если можно сделать идемпотентным (а это можно и нужно всегда — интернет по определению не надежен) — то нужно делать.

Сам по себе запрос — это просто транспорт неких данных. Он не может быть идемпотен или нет. В спецификации протокола HTTP просто нет такого слова.

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

Pzz>Сам по себе запрос — это просто транспорт неких данных. Он не может быть идемпотен или нет. В спецификации протокола HTTP просто нет такого слова.
9.1.2 Idempotent Methods