Если ты собираешься ранить эту Джобу на дженкинсе то ты можешь использовать переменную окружения JOB_ID как уникальный ключ, и таким образом ты избежишь конфликта id
У меня есть ID и CURRENCY в реквесте Возвращает мне API номер кошелька созданного по запросу, например 89. Мне надо проверить, что когда я посылаю ID на API, нет ли такого ID уже и если есть, выводить какое-то сообщение
У меня есть ID и CURRENCY в реквесте Возвращает мне API номер кошелька созданного по запросу, например 89. Мне надо проверить, что когда я посылаю ID на API, нет ли такого ID уже и если есть, выводить какое-то сообщение
в таких системах id должны быть длиннее например id: "a4ac8a31-6ccb-4246-8e53-f4fde335387e" для безопасности
POST mysite.com/users с пейлоадом {'name':'John', 'lastname':'Wick'}
возвращает тебе ответ 200 OK, {'id:'105105'}
далее проверять что есть созданный ресурс ты будешь либо по GET mysite.com/users/105105 где 200 OK и хэшмап с данными пользователя означает что юзер есть в системе
не должно быть последовательностей типа id = 0 ... 10000000, при уязвимости можно перебрать всех пользователей в системе, а при случайном id получить другие id сложнее
"проверить нет ли такой айди уже" что вы проверяете этим самым? если вы не указываете айди при создании. то логично предположить, что база данных сама как-то разруливает автоинкремент сущностей ID ну или генерит GUID
POST mysite.com/users с пейлоадом {'name':'John', 'lastname':'Wick'}
возвращает тебе ответ 200 OK, {'id:'105105'}
далее проверять что есть созданный ресурс ты будешь либо по GET mysite.com/users/105105 где 200 OK и хэшмап с данными пользователя означает что юзер есть в системе
а
404 Not Found что его нет
Только у меня не 404, а 500 ошибка в случае, если ИД повторяется. а, то есть я могу сделать проверку по коду? Если скажем 404 или 500, то system out print (Такой пользователь есть в базе) Так?