Проблема API-ключей, которые никогда не истекают
Ключ, выданный много лет назад, ни разу не заменённый и до сих пор действующий, это не удобство. Это риск, на который никто не смотрел уже много лет.
Против доплаты за базовые способы аутентификации
Аутентификация относится к наиболее рутинным сторонам работы с API, и это как раз та рутинная деталь, которую запирают за тарифным планом чаще, чем следовало бы. Некоторые провайдеры оставляют отдельные методы аутентификации, HTTP Basic auth или схему с Bearer-токеном, для более дорогих тарифов, а младший тариф поддерживает только один определённый формат заголовка. Техническая разница в стоимости проверки одного способа аутентификации и другого почти нулевая. Отличается лишь то, насколько каждый из них удобен для существующего кода конкретного клиента, а это никак не связано с тем, сколько клиент вообще должен платить за использование API.
Мы принимаем ключ в заголовке X-API-Key, в заголовке Authorization Bearer, через HTTP Basic auth с ключом в качестве имени пользователя или в параметре запроса, на каждом хосте и без доплаты за любой из этих способов. Какая бы схема уже ни подходила вашему существующему коду, какую бы библиотеку или внутреннее соглашение ваша команда ни использовала для других API, она, скорее всего, уже поддерживается, и вам не придётся ничего перестраивать только ради формата, который мы случайно предпочли.
Логика разделения методов аутентификации по тарифам на самом деле связана не со стоимостью. Речь идёт о дифференциации тарифов ради самой дифференциации: о поиске функций, которые можно оставить для более платёжеспособного клиента, даже если их предоставление ничего не стоит, просто потому что чем больше функций заперто за старшим тарифом, тем ценнее он выглядит в сравнительной таблице. Методы аутентификации легко становятся такой мишенью, потому что поддержка нескольких из них действительно требует мало усилий от провайдера и действительно удобна для клиента, и поэтому ограничивать их означает принимать чисто монетизационное решение, а не решение, основанное на какой-либо реальной разнице в стоимости.
Мы считаем, что такие ограничения незаметно наказывают разработчиков за решение, которое никак не связано с тем, какую ценность они получают от самих данных. Команда, чьи инструменты по умолчанию используют Bearer-токены, не должна платить больше, чем команда, чьи инструменты по умолчанию используют собственный заголовок, когда обе команды делают один и тот же запрос и получают один и тот же ответ. Ценность продукта заключается в ответе. Метод аутентификации это просто трубы, и у труб не должно быть ценника, зависящего от того, какая из них подходит к вашей существующей стене.
Здесь действует и более широкий принцип, выходящий за рамки аутентификации: функции, которые ничего дополнительно не стоят провайдеру, не должны превращаться в искусственные границы между тарифами лишь потому, что это возможно. Тарифная структура, построенная на реальной разнице в затратах, например на объёме запросов, вполне обоснованна. Тарифная структура, раздутая недорогими удобствами, оставленными для тех, кто платит больше, существует в основном для того, чтобы страница цен выглядела более разнообразной, чем на самом деле является сам продукт.