Информация об изменениях

Сообщение Re[7]: Идемпотентность POST - хорошая ли практика? от 20.09.2022 14:12

Изменено 20.09.2022 14:36 karbofos42

Re[7]: Идемпотентность POST - хорошая ли практика?
Здравствуйте, Ночной Смотрящий, Вы писали:

НС>В общем случае это невозможно. У тебя может запрос на удаление успешно дойти, а вот отклик сервера потеряться. При таком раскладе, если DELETE будет возвращать при удалении уже удаленного 404, ты никогда не получишь на клиенте для этого ресурса 200.

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

Так если я не получу ответ от сервера, то клиент повторно ему запрос на удаление отправит (TCP же и всё такое).
Дальше и появляется вопрос:
либо сервер увидит, что это повтор уже обработанного запроса и ответит то же самое, что отвечал уже и оно потерялось
либо серверу плевать, он обработает ещё раз удаление и уже не 200, а 404 отправит.
Кроме удаления по ИД, может быть и удаление по какому-нибудь условию.
И будет странно, если "потерянный" запрос сначала удалит 10 записей в БД, а потом я пользователю покажу, якобы не удалилось ничего.
Сначала пользователь удивится почему это ничего не удалилось, ведь он правильно всё выбрал.
Потом он удивится, когда увидит, что данных действительно больше нет.
И в третий раз удивится, когда начнёт искать в журнале/логе кто там его данные удалил и увидит, что это он.
А разработчики потом будут искать отличный баг про неправильное сообщение пользователю.
Re[7]: Идемпотентность POST - хорошая ли практика?
Здравствуйте, Ночной Смотрящий, Вы писали:

НС>В общем случае это невозможно. У тебя может запрос на удаление успешно дойти, а вот отклик сервера потеряться. При таком раскладе, если DELETE будет возвращать при удалении уже удаленного 404, ты никогда не получишь на клиенте для этого ресурса 200.

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

Так если я не получу ответ от сервера, то клиент повторно ему запрос на удаление отправит, когда связь восстановится (либо вообще это в рамках TCP разрулится и разработчика не волнует).
Дальше и появляется вопрос:
либо сервер увидит, что это повтор уже обработанного запроса и ответит то же самое, что отвечал уже и оно потерялось
либо серверу плевать, он обработает ещё раз удаление и уже не 200, а 404 отправит.
Кроме удаления по ИД, может быть и удаление по какому-нибудь условию.
И будет странно, если "потерянный" запрос сначала удалит 10 записей в БД, а потом я пользователю покажу, якобы не удалилось ничего.
Сначала пользователь удивится почему это ничего не удалилось, ведь он правильно всё выбрал.
Потом он удивится, когда увидит, что данных действительно больше нет.
И в третий раз удивится, когда начнёт искать в журнале/логе кто там его данные удалил и увидит, что это он.
А разработчики потом будут искать отличный баг про неправильное сообщение пользователю.