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

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

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

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

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

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

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

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

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

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

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

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

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

Здравствуйте, 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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Здравствуйте, 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. ??? думает пользователь.

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

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

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

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

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

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

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


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

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

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

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

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

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

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