Приветствую.
Подскажите как правильно реализовать идемпотентность для запросов к сервисам API?
Сайт на WP, выполняет запросы к платежному шлюзу.
В параметрах нужно передавать ключ идемпотентности.
Что в таком случае нужно использовать?
Или точнее где хранить ключ, если потребуется повторить запрос?
К примеру клиент приходит на стр. оплаты, заполняет форму и нажимает "Оплатить".
Нужно сгенерить уникальный ключ идемпотентности и отправить запрос на создание платежа.
Такой запрос содержит приватные данные, поэтому отправляться будет с сервера.
Вместе с запросом умрут и все его данные, когда он будет завершен.
При этом, допустим, возникнет необходимость отправить запрос повторно.
Где все это время хранить созданный для этого Idempotence-Key?
Записать в куки, или работать с сессией, или писать в бд?
Как это делается правильно? Поделитесь пожалуйста опытом.
Как этот ключ обновлять, в случае успешной оплаты? Вдруг клиенту нужно будет сделать второй платеж.
После того, как платеж прошел, клиент возвращается на сайт по указанной ссылке (confirmation->return_url), можно, например, здесь проверить наличие куки (если хранить в ней) и удалить ее.
Дмитрий, Такое поведение помогает избежать нежелательного повторения транзакций. Например, если при проведении платежа возникли проблемы с сетью, и соединение прервалось, вы сможете безопасно повторить нужный запрос неограниченное количество раз.
Вот здесь увлекательная история об идемпотентности.
Дмитрий, У вас хорошее чувство юмора, попробуйте подключить мозг, тоже бывает полезно.
Ну или почитайте документацию платежных сервисов. Можете им объяснить, что ключ идемпонентности, обязательный параметр, нужен только чтобы заказать такси. Успехов.
Andrey Dontsov, Пробую. В вашей ссылке обращение к апи приводили к выделению/освобождению ресурсов (такси) - и тут да, нужна идемпонентность. И если бы вы работали напрямую с счетом пользователя - да. Заблочили средства, запрос умер, повторили - а денег насчету уже не хватает, первый запрос по таймауту умер, а второй не выполнится. Потеряли свою прибыль. Куда без нее.
Однако в случае платежных шлюзов, прежде чем что то там где то какой то ресурс выделится у вашего запроса будет такое состояние - что вам прилетит какой нибудь постбэк асинхронно. Во всех других случаях гибель запроса никаких ресурсов не заблочит. И по этому если реально включить мозги - то в вашем случае идемпонентность вам нужна как собаке пятая нога.
Дмитрий, Уважаемый, спасибо за вашу активность. Я не сам себе изобретаю, что нужно, а что нет для создания платежа. Ключ идемпонентности - обязательный параметр. Это требует платежный сервис, понимаете? Посмотрите документацию.
Пятая нога, шестая или другая - объясните это разработчикам сервиса, ок?
Давайте без шуток, в благодарность за ваши комментарии (вы же хотели помочь, верно?), показываю результат обращения к сервису, без ключа идемпонентности. Это запрос на создание платежа:
{
"type" : "error",
"id" : "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx",
"code" : "invalid_request",
"description" : "Idempotence key is missing. Generate a unique key is specify it in the Idempotence-Key header",
"parameter" : "Idempotence-Key"
}
Расскажите потом, удалось убедить разрабов сервиса, что ключ не нужен, лишний и вот эту историю с собакой. Тут всем будет полезно.
Расскажите потом, удалось убедить разрабов сервиса, что ключ не нужен, лишний и вот эту историю с собакой. Тут всем будет полезно.
Обязательно. Но тут в чем трабла, попробую обьяснить проще. Ключ идемпонентности, будет ключом идемпонентности только в случае того что вы его будете хранить и использовать в повторных запросах. А без этого это будет банальный id запроса без которого никуда. А если взять и пойти чуток дальше первой строчки документации: это можно прочитать
Если вы повторяете запрос с теми же данными и тем же ключом, API обрабатывает его как повторный. Если данные в запросе те же, а ключ идемпотентности отличается, запрос выполняется как новый.
А если открыть скажем официальную библиотеку для работы с юкассой можно встретить код:
где легким движением кладется болт на всю эту вашу идемпонентность. По этому можно оставить эти фантазии насчет требований разрабов, и включив мозги вернуться к моему изначальному вопросу:
А зачем отправлять повторно с тем же ключом?
Иииии так - нахрена? У вас остались подсказки - помощь зала, звонок другу и 50 на 50
По первому пункту "...если пойти чуток дальше первой строчки документации" - спасибо, но это именно то, что я вам скидывал и хотел, чтобы вы прочитали. Вы молодец, справились.
Код вижу, и это самое интересное.
Игнор и принудительная генерация ключа реализована (внимание) только в клиенте.
Т.е. через оф. клиента платеж будет создан в любом случае, это видно в исходниках и я провел тесты.
Но..
Прямые запросы к API, стабильно возвращают ошибку в обоих случаях, и если Idempotence key не передан вовсе и если передан со значением null. Такие дела).
Ответ сервиса на запросы без ключа всегда одинаковый - "Invalid request: Idempotence key is missing. Generate a unique key is specify it in the Idempotence-Key header".
Вы, возможно, скажете, мол как же так, надо пользоваться официальным клиентом, и будете правы, но на момент написания вопроса здесь, в этом нет необходимости. Прежде чем садится писать решение, подключать клиента и т.д., я провел несколько платежей запросами к API, понял что есть вопросы и попросил здешнее сообщество поделиться опытом, как работать с идемпонентностью.
Спасибо, что втянули меня в это, теперь мы знаем больше).
Отвечая на вопрос "Зачем отправлять повторно с тем же ключом?"
Например, у клиента слабый мобильный интернет, он едет в автомобиле, заполняет данные формы, нажимает "Оплатить", оправляется запрос на создание платежа, но ответ не успевает вернуться клиенту, т.к. инет слабый и ровно в этот момент он въезжает в туннель, где связь пропадает. Клиентский скрипт отрабатывает, выдает уведомление, разблокирует кнопку оплаты и предлагает отправить запрос повторно. На выезде из туннеля клиент нажимает кнопку повторно, с теми же данными и тем же ключом. Тогда сервис отвечает уже созданным объектом платежа, срабатывает логика и клиент направляется на страницу оплаты ЮКасса, если реализовано именно такое поведение. Просто сервис предлагает разные варианты.
Туннель, лифт, подземный переход.. что угодно в связке со слабой мобильной связью.
Дмитрий, Еще довольно смешной момент). Вы приводите мне цитату, текст из документации, который я должен был прочитать, если бы пошел "чуток дальше первой строчки".
Вот ваш текст: "А если взять и пойти чуток дальше первой строчки документации: это можно прочитать.."
Но это именно тот текст, который я отправил вам в ответ на самый первый ваш комментарий.
Согласитесь это смешно).
Получается, если бы пошли чуток дальше первой строчки, вы бы увидели тоже самое)), что потрудились скопипастить из доки мне.
спасибо, но это именно то, что я вам скидывал и хотел, чтобы вы прочитали. Вы молодец, справились.
Буду спать спокойно.
Т.е. через оф. клиента платеж будет создан в любом случае, это видно в исходниках и я провел тесты.
Да при каждой попытке оплаты они будут генерить ключ. Имподентности нет и хрен с ней. Можете считать что Idempotence-Key это у вас какой то Invoice Id. Никакая имподентность вам нахрен не нужна. Каждый раз тупо генерите ключ.
Туннель, лифт, подземный переход.. что угодно в связке со слабой мобильной связью.
Клиент зашел на оплату вы сгенереровали ключ - отправили запрос, запрос сдох в пути, клиент вернулся вы сгенерировали еще раз - и так пока клиент не вылезет из туннеля и не дойдет до успеха в платеже. После этого вам на интернет клиента становится плевать - ибо вам на postback url прилетит уведомление от шлюза что платеж с таким то ключом успешен - бабло зачислено, вы помечаете заказ или что у вас там - оплаченым и клиент внезапно увидит что заказ оплачен и кнопочка оплатить не активна. Алллилуя. Ровно как в оф библиотеке. При этом да. Внезапно этот ключ будет необходим - потому что платежный шлюз хочет быть увереным в том что вы его где то храните и когда вам прилетит уведомление об успешной оплате или неуспешной - вы сможете это обработать
ИИИИИИ вопрос повторяется - зачем вам этот гемморой с повторным использованием ключа? Какие ресурсы вы блокируете что бы париться? Бабки клиента? Уверяю вас если найдется платежный шлюз который будет так обращаться с бабками клиента - он вылетит в трубу. В чем цимес? Какова прибыль? Зачем? Почему? Сядьте и подумайте.
Стоят верблюд-сын и верблюд-отец. Сын спрашивает:
— Папа, а зачем нам на спине нужен горб?
— В горбу, сынок мы накапливаем воду. Когда мы идём по пустыне, нас не мучает жажда.
— Папа, а зачем нам такие копыта?
— Это чтобы в пустыне ноги не проваливались в песок.
— А зачем нам такие большие и жёсткие губы?
— Это чтобы в пустыне можно было есть колючки.
— Тогда, папа, объясни мне, на кой чёрт нам весь этот тюнинг в Саратовском зоопарке?..
И так. Нахрена вам повторное использование ключа?
Вы, возможно, скажете, мол как же так
Я вам скажу одну вещь точно. Если вы пришли на какой то ресурс за помощью и вам внезапно задают вопросы - это не потому что кто то что то не знает. А потому что пытаются уточнить контекст задачи, ибо серебрянной пули не существует - и в одном контексте это решение будет необходимом, в другом - нахер не нужным. По этому не стоит им давать ссылки на статьи, обьяснять какие то термины - нужно обьяснять контекст. В вашем случае - вот уже нцатое время вы не можете обьяснить зачем вам горб в саратовском зоопарке
Да при каждой попытке оплаты они будут генерить ключ.
Вы вообще со мной разговариваете? Ответы сервиса видите? - Нет!!! Сервис НЕ будет генерить ключ. Вообще. Никак. Точка! Он будет возвращать "invalid_request". Очнитесь.
Генерит ключ каждый раз исключительно Клиент, но не API, на который Клиент шлет запросы. Обратиться к API без ключа не получится.
Нужна вам идемпонентность или нет, решайте сами для своих проектов.
Я задал здесь вопрос и адекватные люди на него ответили ниже.
Вам респект, что не сдаетесь, даже по бреду.
На этом все. Дальше можно только ходить по кругу.
Проспитесь и предложение за предложением перечитайте этот диалог, поймете как работает сервис, клиент, что такое идемпонентность и зачем она нужна. Дальше решите нужна ли она лично вам. Успехов.
Вы вообще со мной разговариваете? Ответы сервиса видите? - Нет!!! Сервис НЕ будет генерить ключ. Вообще. Никак. Точка! Он будет возвращать "invalid_request". Очнитесь.
Ага с вами. "они будут генерить ключ" - они это не платежный терминал, а они разработчики библиотеки, мы ж блин говорим об официальной библиотеки.. Более того если вы прекратите истерить и начнете читать внимательно, буквально в следующей строке "Никакая имподентность вам нахрен не нужна. Каждый раз тупо генерите ключ.", вы генерите, раз уж официальная библиотека вам не зашла, а в следующем абзаце где я пытался вдолбить вам логику работы, я вам несколько раз написал кто генерирует ключ "вы сгенереровали ключ - отправили запрос, запрос сдох в пути, клиент вернулся вы сгенерировали еще раз" - ну вроде не бином ньютона. Вас тыкают носом в то что ключ сохранять не надо для повторного использовани, имподентность вам не нужна, но сам ключ генерировать надо - по нему будете постбэки ловить - а вы это не в состоянии прочитать.
На этом все. Дальше можно только ходить по кругу.
А давайте совсем просто. Что бы моя младшая дочь смогла осилить. Берем две ситуации:
1. Ложим болт на имподентность - генерим ключ при каждой попытке оплаты. Отправляем каждый раз новый ключ.
2. Не ложим болт на имподентность - генерим ключ один раз, сохраняем его, или пишем какую нибудь функцию генерации на основе какого нибудь Order ID, и его содержимого и отправляем один и тот же ключ.
В чем КОНКРЕТНО в вашей ситуации 2 вариант будет иметь преимущество? Две строки, один вопрос. Сможете осилить?
Дмитрий, Дмитрий, при всем уважении, вы сами себе пытаетесь что-то объяснить, сами придумали вопросы, которых вам не задавали, сами себе назначили тему разговора и контекст, о чем идет речь.
мы ж блин говорим об официальной библиотеки
Нет. Это вы говорите о библиотеке (Клиенте), я говорю о сервисе API, с которым этот Клиент работает.
Никакая имподентность вам нахрен не нужна
Я не спрашивал нужна или нет. Вы не найдете такого вопроса здесь.
Некоторые ваши пояснения вообще за гранью:
я вам несколько раз написал кто генерирует ключ
Где вы нашли вопрос от меня "Помогите понять кто должен генерить ключ?".
Зачем и главное кому, вы "несколько раз" это написали?!
Вопросы риторические, отвечать не нужно. Разве только себе.
Прочитайте внимательно вопрос и описание вопроса этого поста. Не этого комментария, а главный вопрос страницы.
Обратите внимание, как адекватные люди, без дополнительных вопросов и демагогии, неуместных шуток, анекдотов, пятой ноги у собаки и т.п., быстро и точно дали ответ на вопрос поста. Задумайтесь над этим.
Услышьте меня. Спасибо за все.
Тут много воды, но есть и полезное, я вам за это благодарен.
Чтобы у вас не осталось осадка, что я не ответил на ваши два максимально простых вопроса, отвечу.
Но извините, если вам не понравится. С этим помочь не смогу.
Итак - я НЕ смогу ответить вам более подробно, чем описано в статье "Стажёр Вася и его истории об идемпотентности API", ссылку на которую я давал вам выше.
Если вас что-то не устраивает, не понимаете зачем это нужно, не считаете это обоснованным, не желаете этим пользоваться и что угодно другое - отлично, вы молодец.
Я не спрашивал нужна или нет. Вы не найдете такого вопроса здесь.
Вы спросили как ее реализовать - вам задали вопрос - нахрена.
Итак - я НЕ смогу ответить вам более подробно, чем описано в статье "Стажёр Вася и его истории об идемпотентности API", ссылку на которую я давал вам выше.
И в 3 раз вам говорят, в вашей статье вызов АПИ блочит ресурсы, меняет состояние обьектов, вне зависимости от того успешный он или нет. Там нужна идемпотентность потому что 100 запросов утерянных по пути - приведет к тому что все ресурсы будут заблокированы, и даже сам клиент не сможет ими воспользоваться - не говоря о других клиентах. В вашем случае запрос ничего не заблокирует, если он не успешен, вы можете отправить миллион не успешных запросов - это никак не изменит состояние ресурсов, обьектов, ровно до того момента как запрос не станет успешным, как он только станет успешным вам прилетит постбэк абсолютно не связанный с плохим интернетом клиента. То есть в статье описана одна ситуация, в вашей конкретно ситуации совершенно другая. Не я понимаю что слово идемпотентность красивое звонкое, но в айти любой подход, любой инструмент, любой паттерн/антипаттерн имеет свою область применения. И вашем случае разница между этим двумя вариантами ровно одна - второй вариант потребует чуть больше кода. Все, точка - области применения нет. Выгод вы с этого не получите, только нарушение принципа KISS - Keep It Simple, Stupid - не надо тащить функционал поверх необходимого. Этот вывод можно было сделать по первому моему вопросу, если бы вы взяли на себя труд задуматься.
По этому вы не ответили. вопрос звучал как "В чем КОНКРЕТНО в вашей ситуации". Я даже выделили заглавными буквами. Окей давайте подчеркну еще раз:
В чем КОНКРЕТНО в вашей ситуации 2 вариант будет иметь преимущество? Две строки, один вопрос. Сможете осилить?
Зачем яндексу - видно из статьи. Блокировка ресурсов. Более того я и раньше знал зачем нужна идемпотентность. Но мы говорим о вашем конкретном случае - обращении к АПИ платежного шлюза ЮКассы. В вашем конкретном случае - выгода в чем?
З.Ы. Слушайте если не секрет - сколько вам лет? Обьясняю контекст вопроса - у меня мама заслуженный учитель, высшая категория, все регалии, все дела. Слава богу давно уже на пенсии, но тем не менее - у нас есть с ней давний спор, она говорит что нынешняя молодежь имеет "клиповое мышление", оно не в состоянии строить цепочки. Я всегда отвечал что мол каждое прежнее поколение ныло что молодежь глупеет. Но вот я встретил вас, человека который умудрился заблудиться в 3 фактах, и мне тупо интересно - я уже проиграл или нет?
Дмитрий, А зачем отправлять запросы с одинаковыми параметрами и каждый раз создавать новый платеж?
Как может получиться, что клиент (человек на сайте), отправит данные дважды, повторяться не будем.
Только не надо говорить "А какая разница?", вопрос зачем? Зачем, по вашему, создавать новый объект платежа, если данные неизменны?
Зачем API ЮКассы обеспечивает идемпонентность запросов в 100% случаев?
Это ведь не такси, зачем это им? По вашей логике, это функционал поверх необходимого.
Напомню, что вы не сможете обратиться к API ЮКассы без ключа. Никак.
Пойду вам на встречу.
В нашем случае, перед оплатой, заказчик уже имеет на руках номер договора.
Его же он вводит в форму оплаты, это обязательное поле.
Требование такое, чтобы по одному и тому же номеру договора, платеж может быть только один.
Это годами устоялось, клиент привык к такому поведению и осознанно не желает это менять.
Привык, т.к. основной метод приема платежей работает именно так, ЮКасса подключается как дополнительный, альтернативный способ.
Зачем, по вашему, создавать новый объект платежа, если данные неизменны?
Потому что реализация идемпотентности требует ресурсов сервера? А если у вас не поделка на 3 пользователей в год к таким вещам стоит относится бережно? Потому что реализация идемпотентности требует дополнительного кода? А если у вас кодовая база не на 5 строк, а на сотни тысяч или миллионы - не нужный функционал это плохо? Потому что реализация идемпотентности требует времени программиста? А если у вас зп не аникейщика 50к в месяц, а нормальный миддл от 150к, этот праздник за их счет не нужен конторе?
Зачем API ЮКассы обеспечивает идемпонентность запросов в 100% случаев?
Напомню, что вы не сможете обратиться к API ЮКассы без ключа. Никак.
АПИ ЮКассы имеет возможность идемпонентности запросов. Но обязательным оно не является что можно увидеть в доке, или в коде оф. библиотеки. Сам id платежа, ну или ключ в этой дискуссии - является обязательным потому что именно по нему вы будете обмениваться с ЮКассой о том успешен ли ваш платеж или нет.
Это ведь не такси, зачем это им? По вашей логике, это функционал поверх необходимого.
Вариантов может быть миллион. Возможно в бытность яндекс кассой у них были какие то варианты платежа которые блочили ресурсы - и они хотели как либо лимитировать это. Возможно что какой нибудь манагер с клиповым мышлением прочитал термин и загорелся - в больших конторах такое легко. Не готов говорить на счет яндекса, но какой нибудь майл.ру - ваще не вопрос. В любом случае наличие какого то функционала не повод тащить его к себе.
Мужчину судят за самогоноварение, так как нашли у него дома самогонный аппарат.
- Вы признаете, что гоните самогон?
- Нет, не гоню!
- Аппарат есть, значит гоните!
- Не гоню!
- Ваше последнее слово!
- Прошу судить меня также и за изнасилование!
- А вы еще и кого-то изнасиловали?!
- Нет, но аппарат есть!
Требование такое, чтобы по одному и тому же номеру договора, платеж может быть только один.
Это годами устоялось, клиент привык к такому поведению и осознанно не желает это менять.
Привык, т.к. основной метод приема платежей работает именно так, ЮКасса подключается как дополнительный, альтернативный способ.
Он и будет один. У вас будет сто попыток платежа, и только один успешный - который и будет считаться собственно платежом. То что у ста прежних попыток платежа будет тот же номер договора - вам как мешать то будет? Вы собираетесь строить пользователю список не успешных платежей? Или чего? Как это вообще может коснуться пользователя?
Что значит "id ну или ключ" - ключ идемпонентности (Idempotence-Key) и id платежа (payment_id) - это разные вещи. Вы чего?
Давайте так.
Упростим просто для примера Idempotence-Key до номера договора.
Будем передавать номер договора, как значение заголовка "Idempotence-Key".
Это гарантирует, что объект платежа для этого номера договора будет создан только один раз.
При повторном запросе на создание платежа с этим же "Idempotence-Key", api вернет уже созданный платеж. Сервис НЕ будет создавать новый объект платежа для одного и того же "Idempotence-Key".
В ответе на успешно созданный платеж, будет содержаться его {payment_id}, по которому можно будет запросить информацию о платеже и его актуальном статусе.
ключ идемпонентности (Idempotence-Key) и id платежа (payment_id) - это разные вещи. Вы чего?
Возможно - мне лень читать всю доку.
Упростим просто для примера Idempotence-Key до номера договора.
Если у вас УЖЕ есть уникальное поле, которое можно использовать как параметр идемпотентности, тогда ваш изначальный вопрос как его хранить или как генерировать вообще о чем? Вы не знаете как хранить номер договора? Или что значит "что использовать для ключа идемпотентности" - у вас же номер договора?
Он и будет один. У вас будет сто попыток платежа, и только один успешный - который и будет считаться собственно платежом.
Вот это тоже не верно. Вы НЕ понимаете как работает сервис, вот и всё.
Здесь можно ставить точку.
При ста попытках без "Idempotence-Key" будет создано 100 платежей, которые будут висеть в ЛК ЮКасса в статусе "Не оплачен". И только если 101 будет успешным, в аналитике будет 101 платеж.
100 в статусе "Не оплачен".
1 в статусе "Оплачен".
Это не предположение, это факт.
Я бы вам показал скрин, но в комментарий не приложить.
Я надеюсь это финал).
Вопрос здесь был задан, т.к. до этого момента, номера договоров не хранились в БД сайта, за ненадобностью.
Прежде чем писать код, я попросил сообщество поделиться опытом.
Без правок копирую из своего же вопроса:
Где все это время хранить созданный для этого Idempotence-Key?
Записать в куки, или работать с сессией, или писать в бд?
Как это делается правильно? Поделитесь пожалуйста опытом.
Поскольку это вырвано из контекста, поясню, вопрос "Как это делается правильно?" - не про то, как сохранить значение в базу. Надеюсь это понятно.
Александр Талалаев, чей ответ я отметил решением, дал конкретный ответ. Сразу. Понимаете?
Вы же втянули меня в такой блудняк.. но это было здорово). Уже в 10й раз говорю вам спасибо.
Ну, по рукам? Или опять не слава богу?
Вот это тоже не верно. Вы НЕ понимаете как работает сервис, вот и всё.
Здесь можно ставить точку.
Нееее. Вы не в состоянии обьяснить контекст задачи.
При ста попытках без "Idempotence-Key" будет создано 100 платежей, которые будут висеть в ЛК ЮКасса в статусе "Не оплачен". И только если 101 будет успешным, в аналитике будет 101 платеж.
В лк владельца сайта? То есть под клиентом подразумевается владелец сайта, и при виде не успешных платежей он либо потеряет сознание или в истерике начнет крушить окружающую реальность? Мои соболезнования. А фильтр "Только успешные платежи" не спасет отца русской демократии?
Вопрос здесь был задан, т.к. до этого момента, номера договоров не хранились в БД сайта, за ненадобностью. Прежде чем писать код, я попросил сообщество поделиться опытом.
Ну то есть вы попытались выглядеть не так глупо - но клиповое мышление, начальный вопрос забыли и стало совсем смешно?
Александр Талалаев, чей ответ я отметил решением, дал конкретный ответ. Сразу. Понимаете?
Я бы наверное отсоветовал использовать функцию crypt, ибо она здесь избыточна, не генерирует строку достаточного размера что будет неудобно, если целью будет получение UUID, как того советуют в доке. И вам стоит поводить мышкой по ссылкам что содержится в моих комментариях там будет библиотека генерации UUID v3, v5 на основе алгоритмов md5 и sha-1, которые для этого и должны использоваться по спецификации, вродь как, и на основе данных которые позволят вам автоматом получать уникальный UUID если содержимое заказа поменялись. Но c вашим подходом похоже что угодно прокатит.
Правда ответ к номеру договора никакого отношения не имеет. :)
Вы же втянули меня в такой блудняк.. но это было здорово). Уже в 10й раз говорю вам спасибо.
В блудняк втянули себя вы. Если бы вы остановились бы и задумались банально на ПЕРВОМ вопросе, - то было бы 2 варианта продолжения. Вы бы поняли что имодентность и возня с сохранением вам не нужна, можно было бы без нее, либо вы описали такой контекст задачи что я бы понял что вам она нужна, и сразу бы предложил вариант генерации UUID на основе данных.
Но вы с какого то перепугу решили что на той стороне провода сидит человек который не знает что такое идемпотентность, и решили обьяснять базовые вещи, приводить статьи которые к вашей задаче отношения не имеют, и нести какую то ахинею в какой-то нелепой попытке не признать что блин просто не дочитал, блин просто не задумался, блин просто решил повыпендриваться - получился блудняк и полная веселуха.
З.Ы. Лет то сколько? Если не секрет. Как мне маме то теперь возражать?
Дмитрий, При чем тут контекст задачи и ваше непонимание работы сервиса ЮКасса?
В лк владельца сайта? То есть под клиентом подразумевается владелец сайта
Да, под клиентом, который делает заказ на сайте, подразумевается владелец сайта. У вас с головой все в порядке?
Я устал комментировать ваш бред. Не вижу смысла продолжать.
В качестве бонуса, как любителю цитат и анекдотов, адресую вам эту известную цитату: Никогда не спорьте с дураками, они стащат вас на свой уровень и задавят опытом.
Эта цитата - контекст, которого вам так не хватает. И в рамках этого контекста сообщаю, вам удалось и первое и второе, и стащить на свой уровень и задавить опытом. Это победа.
Никогда не спорьте с дураками, они стащат вас на свой уровень и задавят опытом.
Да не вопрос. Надеюсь нырнув ко мне на уровень, вам удалось понять и запомнить когда стоит использовать идемпотентность, а когда она будет бесполезной тратой времени и ресурсов, поняли что не надо тащить в рот все что дают вам в руки, хочется верить что таки сходили по ссылке и поняли как генерить UUID на основе данных, и самое главное осознали что на вопрос "зачем вам это", нужно обьяснять контекст задачи, требования, а не пытаться сыпать терминами. Так сказать ныряйте чаще - может станете программистом.
К сантехнику прикрепили практиканта. Вызывают на выезд. Приезжают. Канализационный люк. Из него течет дерьмо. Сантехник подходит к люку и ныряет.
Через минуту выныривает, кричит:
- Ключ на 19.
Снова ныряет. Через полминуты выныривает:
- Прокладку No.6.
Опять ныряет. Выныривает:
- Ключ на 26.
Ныряет. Через минуту выныривает. Выходит, отряхивается и закуривает. Сел, отдышался и говорит практиканту:
- Вот так!.. Учись, студент! А то так и будешь всю жизнь ключи подавать...
С кукисами и прочим оставьте это на стандарты что уже вам даёт WP(и/или плагины что вы там используете).
После нажатия купить, у вас создаётся запись о покупке в БД, со статусом не оплачен. У покупки во всех системах для создания инет магазинов и тп уникальный айди, вот на основе его и можно генерировать уникальный (допустим
с помощью crypt) ключ идемпотентности.
После успешной оплаты в БД статус меняется на оплчен и этот заказ и его айди больше никогда не используется. Даже при повторной покупке это будет уже клон этой, но с новым айди.
Таким образом и себя защитите и в целом простое и относительно надёжное решение.
Могут быть нюансы только когда оплата прошла, а ваш сервис это узнать через обратный webhook не смогла(допустим был лаг и тп) и запись в БД не стала - оплачен. Но обычно платёжные шлюзы даёт проверять статусы оплаты и по запросу, поэтому если не приходит ответ там в течении какого-то времени, можно запрашивать в ручную. Ну и затем в любом случае устаревает запрос на оплату(почти во всех платёжках есть тайм аут на то, в какое время можно оплатить уже после создания инвойса на их стороне), так что и тут в целом все норм.
Александр Талалаев Спасибо за ответ, все очень точно описано, весь функционал в шлюзе сервиса есть.
Нет, не использую плагины, тут это не нужно, подключается один единственный способ оплаты, как дополнительный, к уже имеющимся. Плагин потянет за собой тонну неиспользуемой функциональности.
Получается - писать в БД. Решение понятно.
Пара вопросов.
Сайт без регистрации, как связать именно "этого" клиента с записью покупки в базе?
Например, произошел какой-то лаг, клиент обновил страницу или даже не обновлял, но отправил запрос повторно. Как связать, что это именно он, именно его заказ есть в базе со статусом "Не оплачен"?
Просто генерить уникальную запись для каждого обращения к шлюзу - проблем нет, для этого и БД не нужна, тут же вся суть, если я правильно понимаю идемпотентность, чтобы повторный заказ с теми же параметрами от одного клиента, выдавал один и тот ответ сервиса. Не плодил сущности платежа, каждый раз создавая новый, а возвращал уже созданный платеж в статусе "Pending".
Andrey Dontsov, обычно при чекауте требуют определенные данные которые однозначно идентифицируют пользователя, чаще всего имейл. И да через кукисы всё помечают. В вордпрессе/вукомерс это к примеру условная гостевая(без регистрации) продажа. Есть отдельные плагины которые потом позволяют автоматически линковать эти продажи с зарегистрированным пользователем.
Вот к примеру посмотрите как у вукомерс https://woocommerce.com/document/woocommerce-cookies/
Можете погуглить "guest checkout" с вордпресс.
Я всё же рекомендую, если используете вордпресс, поменьше своих велосипедов и возьмите готовые плагины. для того чтобы не писать свои костыли для базиса всего ворклфлоу продажи.
Пожалуй, плюсану Александру. На паре проектов мне не нужна была корзина и большая часть того, что есть в вп. Я написал свой функционал чекаута, создания заказов, проверка статусов оплаты и тд. Кода получилось дохренища, уже в процессе я понял, что много о чем не подумал перед началом работы ))
Сложный
Простой
