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