Проблема API-ключей, которые никогда не истекают
Ключ, выданный много лет назад, ни разу не заменённый и до сих пор действующий, это не удобство. Это риск, на который никто не смотрел уже много лет.
В чём отрасль до сих пор ошибается с внедрением IPv6
IPv6 доступен уже достаточно давно, чтобы отношение к нему как к второстепенной задаче перестало быть разумным инженерным упрощением, и всё же множество инструментов для работы с IP до сих пор ведут себя так, будто настоящий трафик идёт по IPv4, а IPv6 является исключением, которым займутся, если останется время. Это проявляется в мелочах: логика ограничения частоты запросов написана вокруг блоков адресов в стиле IPv4 без равноценной, продуманной концепции для IPv6, или документация в примерах молчаливо предполагает формат адреса IPv4 и оставляет обработку IPv6 как подразумеваемую запоздалую мысль.
Мы намеренно построили отслеживание квот на уровне сети вокруг обоих семейств адресов, а не как заплатку для IPv6, прикрученную к логике, изначально ориентированной на IPv4. Каждая сеть получает общую бесплатную квоту, блок /24 для адресов IPv4 и блок /48 для адресов IPv6, и обе группировки считаются полноправными, а не так, что одна является основным решением, а другая уступкой. Различие между /24 и /48 не произвольно. Оно отражает то, как каждое семейство адресов на самом деле распределяется региональными интернет-регистраторами, отвечающими за выдачу блоков, поэтому группировка в обоих случаях означает одно и то же на практике: сеть разумного размера.
Ошибка здесь особенно важна для API данных о местоположении и IP, потому что вся категория поисков на уровне сети и по IP зависит от правильного разбора, сопоставления и ограничения частоты запросов для обоих форматов адресов. API, который молчаливо обрабатывает IPv6 как пограничный случай, с большей вероятностью выдаст непоследовательное поведение квот, неверную группировку сетей или прямые ошибки разбора для трафика IPv6, и это именно тогда, когда внедрение IPv6 продолжает расти и заметная доля реальных запросов приходит по нему, а не по IPv4.
Отчасти в отрасли в это недоинвестируют потому, что у многих сервисов трафик IPv4 по-прежнему составляет большую часть общего объёма, из-за чего пограничные случаи IPv6 кажутся низким приоритетом по сравнению с усилиями, которые нужны, чтобы сделать их по-настоящему правильно. Мы считаем, что такое рассуждение слишком сильно недооценивает тенденцию. Доле трафика, которая продолжает расти, плохо служит инфраструктура, относящаяся к ней как к вечному меньшинству, а стоимость правильного исправления обработки IPv6 только растёт, чем дольше основная логика системы строится с IPv4 по умолчанию.
Ничего драматичного в этом утверждении нет. Это просьба относиться к IPv6 так же серьёзно, как к IPv4, при реальном проектировании ограничения частоты запросов, отслеживания квот и логики поиска, а не только ради галочки о соответствии, которая говорит, что API формально принимает адреса IPv6 без синтаксической ошибки. Принимать формат адреса и обрабатывать его с той же тщательностью, что и более распространённый, это разные достижения, и значительная часть инфраструктуры в этой отрасли по-настоящему справилась только с первым.