Проблема API-ключей, которые никогда не истекают
Ключ, выданный много лет назад, ни разу не заменённый и до сих пор действующий, это не удобство. Это риск, на который никто не смотрел уже много лет.
Почему мы считаем пакетные запросы по элементам, а не по вызовам
Пакетный эндпоинт, который принимает тысячу адресов в одном вызове и засчитывает это как один запрос из вашей квоты, выглядит щедро на странице цен. Но это не щедрость. Это погрешность округления, которая ждёт своего часа, чтобы стать проблемой с мощностями, потому что реальная работа за этим вызовом, тысяча отдельных поисков, не уменьшилась оттого, что пришла в одном конверте.
Мы считаем массовые и пакетные запросы так же, как всё остальное: один элемент равен одному запросу. Если вы отправляете тысячу адресов в одном пакетном вызове, это тысяча запросов из вашей бесплатной квоты или вашего предоплаченного баланса, ровно так же, как если бы вы вызвали эндпоинт тысячу раз по отдельности. Удобство пакетирования, то есть меньше сетевых обменов и меньше накладных расходов на соединения, реально и полезно. Стоимость самих поисков не меняется оттого, что вы запросили их вместе.
Искусственно заниженная цена пакетных вызовов создаёт странное искажение. Она поощряет перестраивать интеграцию вокруг крупных пакетных вызовов только ради экономии, а не потому, что пакетная обработка действительно подходит вашему процессу. Кроме того, со стороны становится труднее оценить реальное планирование мощностей провайдера, ведь «запрос» больше не означает одинаковый объём работы. Клиент, который сравнивает провайдеров по числу запросов в день, не сможет сравнить их честно, если запрос одного провайдера может втайне содержать тысячу обращений, а запрос другого нет.
Подсчёт по элементам также сохраняет смысл наших заголовков квоты. Каждый ответ содержит данные о том, сколько вы израсходовали и сколько осталось, и это число что-то значит, только если запрос остаётся запросом независимо от того, в какой форме он отправлен. Если бы пакет из тысячи элементов незаметно стоил одну единицу, эти заголовки почти ничего не говорили бы о вашем реальном расходе, и настоящее число вы узнали бы, только когда гораздо более крупная нагрузка без пакетов упёрлась бы в лимит, которого вы не ожидали.
Есть и аргумент справедливости. Клиент, отправляющий отдельные вызовы, и клиент, отправляющий пакеты, просят нас выполнить одинаковый общий объём работы за одинаковую общую цену. Если брать с клиента с пакетами меньше за каждое обращение только потому, что запросы упакованы вместе, то клиент с отдельными вызовами фактически субсидировал бы инфраструктуру, которую нагружает не он. Одинаковая цена за обращение для обоих привязывает стоимость к работе, а не к тому, как эта работа упакована.
Всё это не делает пакетную обработку бессмысленной. Это по-прежнему правильный способ отправить большой заранее известный набор обращений за один цикл «запрос-ответ», и мы её поддерживаем, потому что меньше соединений и меньше накладных расходов дают реальный выигрыш в эффективности на вашей стороне. Чего пакетная обработка не должна делать ни с одной стороны запроса, так это менять реальную стоимость обращений. Тысяча обращений есть тысяча обращений, приходят ли они по одному в течение дня или все сразу в одном вызове.