Сообщение Re: WebAPI - защита от дублирования - ваш выбор от 01.09.2022 1:37
Изменено 01.09.2022 5:26 DiPaolo
Re: WebAPI - защита от дублирования - ваш выбор
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.
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.
Re: WebAPI - защита от дублирования - ваш выбор
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.
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.