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

S>Допустим, вызываем метод и он создает новый пункт заказа. Хотелось бы чтобы при n вызовах метода добавлялся только 1 пункт заказа (на случай повторных запросов при ошибке сетевой).

Откуда вообще взяться повторному запросу? Если в веб-функцию пришёл запрос, значит сервер уже получил полные данные и никаких "ошибке сетевой" там нет.
Ну и на всякий, поменьше юзать всякое г-но типа JS.

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

S>Допустим, вызываем метод и он создает новый пункт заказа. Хотелось бы чтобы при n вызовах метода добавлялся только 1 пункт заказа (на случай повторных запросов при ошибке сетевой).

Это называется идемпотентные операции, подходы к тому то что тебе нужно ищи по словам "ключ идемпотентности"

S>Варианты:
S>1. GUID.

Да

S>2. Какая-нибудь метка времени + рандомное число, типа 220831215622121 — дата и время включая миллисекунды — уже тип int не вмещает, т.е. long. Ну и могут быть проблемы все-же, если запросы частые (что можно разрулить добавлением еще 3-5 разрядов рандомного числа).

Это создание "как бы guid" вручную. Если есть возможность просто сгенерировать guid — то зачем оно?

S>3. Можно передавать ID пункта заказа, т.е. зная ID предыдущего делать инкремент.

Это один из вариантов построения ключа идемпотентности из самих данных. Другой вариант — вычислять от них хэш. Могут быть свои плюсы в подходе, но как по мне это более сложное и хрупкое решение, чем синтетический ключ наподобие гуида. Надо очень обдуманно выбирать. Но guid тоже не решает волшебно всех проблем, надо применять осмысленно.

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

A>При наличии сетевого соединения между клиентом и сервером никакой метод не может быть идемпотентным, потому что клиент никогда гарантированно не узнает, смог ли выполнится метод на сервере или нет.

Это какая то альтернативная трактовка идемпотентности.

A>Это может произойти при возникновении ошибки такого соединения, где-нибудь посередине вызова метода сервера. Запрос дошел до сервера? Сервер смог обработать запрос? Клиент уже никогда этого не сможет узнать

А клиент и не должен этого знать. У него логика простая — не получил 20X в ответ — делаем ретрай.

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

F>Здравствуйте, Baiker, Вы писали:
B>>Откуда вообще взяться повторному запросу?

F>Сервер-то получил, но вот клиент может ответа от сервера не получить и получить разрыв соединения

Это вполне возможная теоретическая ошибка, но на практике (если юзать HTML адекватно), таких проблем вообще никогда не встречал (потому и спрашиваю, где автор умудрился получить дубликаты).
Когда ты работаешь нормальным путём (т.е. <form action=POST> и т.п.) браузер отсылает запрос и если сервер всё сделал правильно, вероятность ответа близка к 100%.
Ну а если насовать жабоскриптов, да ещё свежеиспечённый погромизд насуёт туда своего говнокода — то да, там хоть 10 запросов будут! Но защищаться тогда надо не от дубликатов, а от мартышек с JS.

S>1. GUID.
S>2. Какая-нибудь метка времени + рандомное число, типа 220831215622121 — дата и время включая миллисекунды — уже тип int не вмещает, т.е. long. Ну и могут быть проблемы все-же, если запросы частые (что можно разрулить добавлением еще 3-5 разрядов рандомного числа).
S>3. Можно передавать ID пункта заказа, т.е. зная ID предыдущего делать инкремент.

Зависит от требований системы. Иногда имеет смысл использовать все три способа. Подробнее описано тут https://stripe.com/blog/idempotency: первый пункт — раздел Guaranteeing “exactly once” semantics, второй и третий — Being a good distributed citizen.

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

B>Откуда вообще взяться повторному запросу? Если в веб-функцию пришёл запрос, значит сервер уже получил полные данные и никаких "ошибке сетевой" там нет.

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

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

S>>2. Какая-нибудь метка времени + рандомное число, типа 220831215622121 — дата и время включая миллисекунды — уже тип int не вмещает, т.е. long. Ну и могут быть проблемы все-же, если запросы частые (что можно разрулить добавлением еще 3-5 разрядов рандомного числа).

F>Это создание "как бы guid" вручную. Если есть возможность просто сгенерировать guid — то зачем оно?

Потому что Guid монструозно и уродливо выглядит.

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

B>Это вполне возможная теоретическая ошибка, но на практике (если юзать HTML адекватно), таких проблем вообще никогда не встречал (потому и спрашиваю, где автор умудрился получить дубликаты).

Ты не встречал, не значит, что ее нет. И нет, протокол http это весьма практическая штука, не теоретическая, и возможные ошибки в нем описаны не зря.

B>Когда ты работаешь нормальным путём (т.е. <form action=POST> и т.п.) браузер отсылает запрос и если сервер всё сделал правильно, вероятность ответа близка к 100%.

"близка к 100%" это сильно. Насколько близка?

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


B>Ну а если насовать жабоскриптов, да ещё свежеиспечённый погромизд насуёт туда своего говнокода — то да, там хоть 10 запросов будут! Но защищаться тогда надо не от дубликатов, а от мартышек с JS.

Ты Kolesiki или его младший брат?

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

B>Откуда вообще взяться повторному запросу?
Ровно оттуда же, откуда возьмется первый запрос. Его отправит клиент, не получивший ответ на первый запрос.

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

S>1. GUID.
S>2. Какая-нибудь метка времени + рандомное число, типа 220831215622121 — дата и время включая миллисекунды — уже тип int не вмещает, т.е. long. Ну и могут быть проблемы все-же, если запросы частые (что можно разрулить добавлением еще 3-5 разрядов рандомного числа).
S>3. Можно передавать ID пункта заказа, т.е. зная ID предыдущего делать инкремент.
S>Что еще?

0. Сделать метод идемпотентным (грубо говоря, заменить POST на PUT)
Идея использовать для идентификатора семантически значимые поля приведет к тому, что в каждом конкретном случае тебе придется изобретать велосипед заново. Поэтому лучше синтетический ключ реквеста, формируемый автоматично в клиенте и передаваемый, с учетом ретраев, в хидере на сервер. Но вариант 0 лучше.

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

НС>>Про какой таймстамп речь? Если про юниховый, то там точность слишком низкая.
S>У соотв. строки в бд. можешь быть timestamp, ну или проще время создания\изменеия. Соотв. вместо id (см. выше),
S>можно исп. timestamp.

Опять какой то непонятный сумбур.

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

НС>>0. Сделать метод идемпотентным (грубо говоря, заменить POST на PUT)
S>Как, если это пункт заказа?

Так. Id пункта заказа генеришь на клиенте. При ретраях id меняться не будет.

S> Может быть два одинаковых пункта заказа. Как отличить так и захотел клиент или же это ошибка из-за повторной отправки запроса?

В коде клиента отличишь. При создании пункта генеришь новый id, при ретрае остается тот же самый.

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

S>Допустим, вызываем метод и он создает новый пункт заказа. Хотелось бы чтобы при n вызовах метода добавлялся только 1 пункт заказа (на случай повторных запросов при ошибке сетевой).

S>Варианты:

Я бы взял GUID конечно, если никаких специальных требований нет, зачем изобретать велосипед

S>long — 8 байт, GUID — 16 байт.

Это не то место, где имеет смысл экономить. Грубо говоря, это 8 Мб лишних данных на миллион записей. Ну это ни о чем.

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

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

B>>Откуда вообще взяться повторному запросу? Если в веб-функцию пришёл запрос, значит сервер уже получил полные данные и никаких "ошибке сетевой" там нет.

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

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

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

B>Это вполне возможная теоретическая ошибка, но на практике (если юзать HTML адекватно), таких проблем вообще никогда не встречал (потому и спрашиваю, где автор умудрился получить дубликаты).

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

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

Q>Для отмены используем ключ идемпотентности того запроса, который отменяем.

А исходный вопрос ТС, по сути, и есть "как мне создать ключ идемпотентности"

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

Вот именно. Всегда надо смотреть что нужно в конкретном случае

Допустим, вызываем метод и он создает новый пункт заказа. Хотелось бы чтобы при n вызовах метода добавлялся только 1 пункт заказа (на случай повторных запросов при ошибке сетевой).

Варианты:

1. GUID.
2. Какая-нибудь метка времени + рандомное число, типа 220831215622121 — дата и время включая миллисекунды — уже тип int не вмещает, т.е. long. Ну и могут быть проблемы все-же, если запросы частые (что можно разрулить добавлением еще 3-5 разрядов рандомного числа).
3. Можно передавать ID пункта заказа, т.е. зная ID предыдущего делать инкремент.

Что еще?

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

S>Варианты:

S>1. GUID.
S>2. Какая-нибудь метка времени + рандомное число, типа 220831215622121 — дата и время включая миллисекунды — уже тип int не вмещает, т.е. long. Ну и могут быть проблемы все-же, если запросы частые (что можно разрулить добавлением еще 3-5 разрядов рандомного числа).
S>3. Можно передавать ID пункта заказа, т.е. зная ID предыдущего делать инкремент.

S>Что еще?
Помечать состояние списка заказов номером, хэшем (fingerprint, ETag). По сути как коммит в GIT/оптимистическая блокировка. Это более общее решение, годится не только лишь для создания заказа, а вообще для работы со списком сущностей (создание, удаление, модификация)

S>Потому что Guid монструозно и уродливо выглядит.

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

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

DP>Так тебе ж его не глазами читать — положил в базу, оно там лежит себе и периодически используется, и все.

long — 8 байт, GUID — 16 байт.

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

bnk>Я бы взял GUID конечно, если никаких специальных требований нет, зачем изобретать велосипед

Иногда важно восстатавливать исходную последовательность запросов (но, видимо, не в данном случае). Тогда нужен монотонно возрастающий ID, GUID не прокатит.

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

S>Потому что Guid монструозно и уродливо выглядит.

Зачем тебе его смотреть, это ж не correlationid, он только системе нужен. Но если хочешь немонструозно — можешь использовать cuid.

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

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

S>>1. GUID.
S>>2. Какая-нибудь метка времени + рандомное число, типа 220831215622121 — дата и время включая миллисекунды — уже тип int не вмещает, т.е. long. Ну и могут быть проблемы все-же, если запросы частые (что можно разрулить добавлением еще 3-5 разрядов рандомного числа).
S>>3. Можно передавать ID пункта заказа, т.е. зная ID предыдущего делать инкремент.
S>>Что еще?

НС>0. Сделать метод идемпотентным (грубо говоря, заменить POST на PUT)

Как, если это пункт заказа? Может быть два одинаковых пункта заказа. Как отличить так и захотел клиент или же это ошибка из-за повторной отправки запроса?

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

НС>Зачем тебе его смотреть, это ж не correlationid, он только системе нужен. Но если хочешь немонструозно — можешь использовать cuid.

Ну еще зачем 16 байт, если и 8 хватит более чем.

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

НС>>Зачем тебе его смотреть, это ж не correlationid, он только системе нужен. Но если хочешь немонструозно — можешь использовать cuid.
S>Ну еще зачем 16 байт, если и 8 хватит более чем.

cuid slug — от 7 до 10 байт, внутри счетчик, все как ты хочешь.

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

S>Допустим, вызываем метод и он создает новый пункт заказа.
Клиента контроллируете вы или нет? Если вы не контроллируете, то просто говорите, что идентификатор пункта заказа — уникальная (в рамках заказа) строка. Дальше пусть клиент решает.

S>2. Какая-нибудь метка времени + рандомное число, типа 220831215622121 — дата и время включая миллисекунды — уже тип int не вмещает, т.е. long. Ну и могут быть проблемы все-же, если запросы частые (что можно разрулить добавлением еще 3-5 разрядов рандомного числа).
Я в ряде случаев использую инкрементальный счетчик, инициализируемый текущим временем (миллисекунды). Т.е. первый объект имеет время x = currentTimestamp(), второй — x+1 и т.д. Но зависит от сценария, в ряде случаев (много вкладок браузера открыты одновременно после восстановления/перезапуска) такой подход не работает. Я иногда в тестах использую. "Частые запросы" далеко не всегда проблема. Если у вас один запущенный клиент, идентификаторы позиций являются локальными в рамках заказа, то вероятность накликать две позиции с разницей меньше миллисекунды очень мала.

S>Что еще?
Put на /order/{orderId}/items со _всеми_ позициями заказа. Т.е. просто переписывать все. Иногда работает, иногда нет. Так как у вас был третий вариант (на основе предыдущего пункта заказа) — скорее всего работает.

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

НС>0. Сделать метод идемпотентным (грубо говоря, заменить POST на PUT)

При наличии сетевого соединения между клиентом и сервером никакой метод не может быть идемпотентным просто так, потому что клиент никогда гарантированно не узнает, смог ли выполнится метод на сервере или нет. Это может произойти при возникновении ошибки такого соединения, где-нибудь посередине вызова метода сервера. Запрос дошел до сервера? Сервер смог обработать запрос? Клиент уже никогда этого не сможет узнать, следовательно проблема создания повторного запроса (и таким образом заказа) остаётся. Кроме случая когда клиент передает идентификатор. Возвращаемся к тому же GUID'а и подобному.

А какой метод для этого будет использоваться POST или PUT, это просто абстрактное соглашение.

Если подсумировать общие наблюдения, то использование PUT и идентификатора решит проблему автора в соответствии с общепринятыми соглашениями.

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

S>Допустим, вызываем метод и он создает новый пункт заказа. Хотелось бы чтобы при n вызовах метода добавлялся только 1 пункт заказа (на случай повторных запросов при ошибке сетевой).

Только идентификатор. GUID это или что-либо еще — это дело вкуса. Лично я предпочитаю GUID'ы, потому что их не нужно изобретать для каждого такого случая.

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


S>1. GUID.
S>2. Какая-нибудь метка времени + рандомное число, типа 220831215622121 — дата и время включая миллисекунды — уже тип int не вмещает, т.е. long. Ну и могут быть проблемы все-же, если запросы частые (что можно разрулить добавлением еще 3-5 разрядов рандомного числа).
Это называется UUID1, https://gist.github.com/nberardi/3759706 , не подходит если нагрузка большая с одного клиента

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

bnk>>Я бы взял GUID конечно, если никаких специальных требований нет, зачем изобретать велосипед
НС>Иногда важно восстатавливать исходную последовательность запросов (но, видимо, не в данном случае). Тогда нужен монотонно возрастающий ID, GUID не прокатит.1

Обязательно монотонно возрастающий id для этого , timestamp(long) не подойдет?

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

НС>>Иногда важно восстатавливать исходную последовательность запросов (но, видимо, не в данном случае). Тогда нужен монотонно возрастающий ID, GUID не прокатит.1
S>Обязательно монотонно возрастающий id для этого , timestamp(long) не подойдет?

Не понял вопроса.

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

S>>Обязательно монотонно возрастающий id для этого , timestamp(long) не подойдет?
НС>Не понял вопроса.

Помимо id можно timestamp использовать.

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

S>>>Обязательно монотонно возрастающий id для этого , timestamp(long) не подойдет?
НС>>Не понял вопроса.
S>Помимо id можно timestamp использовать.

Что ты понимаешь под id? cuid? guid?
Про какой таймстамп речь? Если про юниховый, то там точность слишком низкая.

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

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

S>>>>Обязательно монотонно возрастающий id для этого , timestamp(long) не подойдет?
НС>>>Не понял вопроса.
S>>Помимо id можно timestamp использовать.
НС>Что ты понимаешь под id? cuid? guid?

монотонно возрастающий id типа int или long.

НС>Про какой таймстамп речь? Если про юниховый, то там точность слишком низкая.

У соотв. строки в бд. можешь быть timestamp, ну или проще время создания\изменеия. Соотв. вместо id (см. выше),
можно исп. timestamp.

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

F>>Сервер-то получил, но вот клиент может ответа от сервера не получить и получить разрыв соединения или таймаут и не знать — то ли это было до того как данные ушли на сервер, то ли уже после, и попробовать повторить операцию.
Q>Если рассматривать http то пользователь получит ошибку, единственное мы не уверены выполнил сервер запрос или нет. Единственное тут лучше для тех случаев, когда ответ пользователю нужен сразу не повторять, а отменять: пользователю показываем ошибку, а очередь на отправку помещает отменяющий запрос, когда связь восстановится эти два запроса уйдут друг за другом на сервер.

Интересная идея. Только маленький вопрос — как правильно уникально идентифицировать "отменяющий" запрос, что он относится именно к вот этому отправленному "оригинальному" запросу, а не какому-то другому, и есть ли тут принципиальная разница с одинаковой идентификацией повторноотправляемого запроса?

Ну и смущает несколько вот такой сценарий:
1. пользователь оформил покупку в инет-магазине через телефон
2. покупка оформилась, на этапе получения ответа клиентское приложение получило ошибку, потому что пользователь заехал в туннель.
3. длинный туннель
4. при выезде из него получил на почту "ваш заказ оформлен и оплачен, ждите курьера"
5. и ушел отменяющий запрос
6. и дальше отменяем запрос, чуть позже пользователь получает сообщение что "жаль что вы передумали, но раз вы так хотите, мы отменим заказ"
7. ??? думает пользователь.

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

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

F>>>Сервер-то получил, но вот клиент может ответа от сервера не получить и получить разрыв соединения или таймаут и не знать — то ли это было до того как данные ушли на сервер, то ли уже после, и попробовать повторить операцию.
Q>>Если рассматривать http то пользователь получит ошибку, единственное мы не уверены выполнил сервер запрос или нет. Единственное тут лучше для тех случаев, когда ответ пользователю нужен сразу не повторять, а отменять: пользователю показываем ошибку, а очередь на отправку помещает отменяющий запрос, когда связь восстановится эти два запроса уйдут друг за другом на сервер.

F>Интересная идея. Только маленький вопрос — как правильно уникально идентифицировать "отменяющий" запрос, что он относится именно к вот этому отправленному "оригинальному" запросу, а не какому-то другому, и есть ли тут принципиальная разница с одинаковой идентификацией повторноотправляемого запроса?

Для отмены используем ключ идемпотентности того запроса, который отменяем.

F>Ну и смущает несколько вот такой сценарий:
F>1. пользователь оформил покупку в инет-магазине через телефон
F>2. покупка оформилась, на этапе получения ответа клиентское приложение получило ошибку, потому что пользователь заехал в туннель.
F>3. длинный туннель
F>4. при выезде из него получил на почту "ваш заказ оформлен и оплачен, ждите курьера"
F>5. и ушел отменяющий запрос
F>6. и дальше отменяем запрос, чуть позже пользователь получает сообщение что "жаль что вы передумали, но раз вы так хотите, мы отменим заказ"
F>7. ??? думает пользователь.

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