Сообщение Re: WebAPI - защита от дублирования - ваш выбор от 31.08.2022 20:57
Изменено 01.09.2022 6:52 fmiracle
Re: WebAPI - защита от дублирования - ваш выбор
Здравствуйте, Shmj, Вы писали:
S>Допустим, вызываем метод и он создает новый пункт заказа. Хотелось бы чтобы при n вызовах метода добавлялся только 1 пункт заказа (на случай повторных запросов при ошибке сетевой).
Это называется идемпотентные операции, подходы к тому то что тебе нужно ищи по словам "ключ идемпотентности"
S>Варианты:
S>1. GUID.
Да
S>2. Какая-нибудь метка времени + рандомное число, типа 220831215622121 — дата и время включая миллисекунды — уже тип int не вмещает, т.е. long. Ну и могут быть проблемы все-же, если запросы частые (что можно разрулить добавлением еще 3-5 разрядов рандомного числа).
Это создание "как бы guid" вручную. Если есть возможность просто сгенерировать guid — то зачем оно?
S>3. Можно передавать ID пункта заказа, т.е. зная ID предыдущего делать инкремент.
Это один из вариантов построения ключа идемпотентности из самих данных. Другой вариант — вычислять от них хэш. Могут быть свои плюсы в подходе, но как по мне это более сложное и хрупкое решение, чем синтетический ключ наподобие гуида. Надо очень обдуманно выбрить. Но guid тоже не решает волшебно всех проблем, надо применять осмысленно.
S>Допустим, вызываем метод и он создает новый пункт заказа. Хотелось бы чтобы при n вызовах метода добавлялся только 1 пункт заказа (на случай повторных запросов при ошибке сетевой).
Это называется идемпотентные операции, подходы к тому то что тебе нужно ищи по словам "ключ идемпотентности"
S>Варианты:
S>1. GUID.
Да
S>2. Какая-нибудь метка времени + рандомное число, типа 220831215622121 — дата и время включая миллисекунды — уже тип int не вмещает, т.е. long. Ну и могут быть проблемы все-же, если запросы частые (что можно разрулить добавлением еще 3-5 разрядов рандомного числа).
Это создание "как бы guid" вручную. Если есть возможность просто сгенерировать guid — то зачем оно?
S>3. Можно передавать ID пункта заказа, т.е. зная ID предыдущего делать инкремент.
Это один из вариантов построения ключа идемпотентности из самих данных. Другой вариант — вычислять от них хэш. Могут быть свои плюсы в подходе, но как по мне это более сложное и хрупкое решение, чем синтетический ключ наподобие гуида. Надо очень обдуманно выбрить. Но guid тоже не решает волшебно всех проблем, надо применять осмысленно.
Re: WebAPI - защита от дублирования - ваш выбор
Здравствуйте, Shmj, Вы писали:
S>Допустим, вызываем метод и он создает новый пункт заказа. Хотелось бы чтобы при n вызовах метода добавлялся только 1 пункт заказа (на случай повторных запросов при ошибке сетевой).
Это называется идемпотентные операции, подходы к тому то что тебе нужно ищи по словам "ключ идемпотентности"
S>Варианты:
S>1. GUID.
Да
S>2. Какая-нибудь метка времени + рандомное число, типа 220831215622121 — дата и время включая миллисекунды — уже тип int не вмещает, т.е. long. Ну и могут быть проблемы все-же, если запросы частые (что можно разрулить добавлением еще 3-5 разрядов рандомного числа).
Это создание "как бы guid" вручную. Если есть возможность просто сгенерировать guid — то зачем оно?
S>3. Можно передавать ID пункта заказа, т.е. зная ID предыдущего делать инкремент.
Это один из вариантов построения ключа идемпотентности из самих данных. Другой вариант — вычислять от них хэш. Могут быть свои плюсы в подходе, но как по мне это более сложное и хрупкое решение, чем синтетический ключ наподобие гуида. Надо очень обдуманно выбирать. Но guid тоже не решает волшебно всех проблем, надо применять осмысленно.
S>Допустим, вызываем метод и он создает новый пункт заказа. Хотелось бы чтобы при n вызовах метода добавлялся только 1 пункт заказа (на случай повторных запросов при ошибке сетевой).
Это называется идемпотентные операции, подходы к тому то что тебе нужно ищи по словам "ключ идемпотентности"
S>Варианты:
S>1. GUID.
Да
S>2. Какая-нибудь метка времени + рандомное число, типа 220831215622121 — дата и время включая миллисекунды — уже тип int не вмещает, т.е. long. Ну и могут быть проблемы все-же, если запросы частые (что можно разрулить добавлением еще 3-5 разрядов рандомного числа).
Это создание "как бы guid" вручную. Если есть возможность просто сгенерировать guid — то зачем оно?
S>3. Можно передавать ID пункта заказа, т.е. зная ID предыдущего делать инкремент.
Это один из вариантов построения ключа идемпотентности из самих данных. Другой вариант — вычислять от них хэш. Могут быть свои плюсы в подходе, но как по мне это более сложное и хрупкое решение, чем синтетический ключ наподобие гуида. Надо очень обдуманно выбирать. Но guid тоже не решает волшебно всех проблем, надо применять осмысленно.