Постоянный статус 429 ... :( : База штрихкодов

Спасибо за ответ.
Я полистал форум и уже понял, что все ответы сводятся к предложению заплатить "смешную сумму". :)
Я и не против - любой труд должен оплачиваться.

Вы просто скажите нормально, что доступ к БД платный, и не надо будет тратить массу сил на поддержание
мнимой бесплатности, защиты от сотен тысяч запросов и т.д. ;)

вы же только что сказали, что ещё одна программа нормально работает... она не моя, кстати...

если есть реальные идеи, как сделать бесплатность не мнимой и не слить базу на сторону - с удовольствием готов обсудить...

Указанная программа не OpenSource и никто не знает какой она запрос делает.
По сути и не важно, хорошо что на есть и можно понять, что проблема не в IP.

Полностью понимаю необходимость защиты данных - это правильно.
А также то, что есть некая, сложившаяся инфраструктура, которую глобально никто перестраивать не будет.

Можно посмотреть, как это реализуется в других системах.
В этом случае простое решение - вообще отказаться от отрытых запросов через REST API и всё.
Сразу уходят все проблемы, навороты с капчами, отслеживание IP, счётчики за месяц, борьба за безопасность и т.д.
Т.е. любой запрос через REST API - с регистрацией на форуме и ключом.

Другой вопрос, что ключ может быть платный без ограничений (как сейчас) или бесплатный,
но например с ограничением по кол-ву запросов в день (50-100) и / или кол-ву товаров в выборке (3-5).
Для простоты - бесплатный ключ может быть e-mail регистрации на форуме, или генериться /указываться в личном кабинете.

В общем-то и всё. Эта схема полностью совместима с текущей работой сервиса.

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

Я, конечно же за всех разработчиков говорить не могу.
Лично мне (как программисту) - эти данные в прикладном значении не интересны.

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

Но пока я даже просто не могу показать, что это вообще такое. С чем и обратился к Вам в первом сообщении.
Обещать юзерам что "всё будет, но после свадьбы" - в современном мире возможностей, не вариант. ;)

P/S: Но я ещё не потерял надежду. Если действительно, маленькая рекламная программка с форума использует
общий доступ, то попробую понять в чём беда у меня … Спасибо за то, что тратите на меня рабочее время. :)

Спасибо ещё раз за помощь - вроде бы я достиг того состояния, когда моя программа работает (или вырубается)
вместе с примером из форума. Это уже что-то … ;) Потом сайт, капча, и ещё несколько запросов проходят. :)

Если позволите, вопрос по содержанию БД штрих-кодов: Вы проверяете их правильность (контрольную сумму) при добавлении ?
Я использовал для теста "неправильный" код 1234567890123 (удобно набирать) - товар по нему найден.

На сколько я в курсе - база не только для EAN-13.

Не стоит целью добавить только EAN-13, там есть и другие коды, которые в это правило не укладываются.
Видимо, кому-то тоже было удобно набирать этот код, причем, не внутренний, а в итоге в двух выгрузках минимум этот товар был.

Понял. Может быть это даже и к лучшему … :)
И уже технологический вопрос: какая максимальная длина пользовательского ключа может быть ?