永不过期的 API 密钥带来的问题
一个多年前签发、从未轮换、至今仍然有效的密钥并不是一种便利。它是一个多年来没有人真正检查过的隐患。
为什么我们宁愿返回错误，也不愿给出错误的猜测
一个总会返回点什么的 API，即使面对它无法很好回答的请求也是如此，表面上看起来比有时返回明确错误的 API 更强大。这种印象具有误导性。一个靠猜测给出答案、而不承认不确定性的响应并不更有用。它更危险，正是因为它看起来和一个自信、正确的响应一模一样，调用方在据此行动之前得不到任何需要进一步核实的信号。
我们宁愿返回明确的错误，或者一个清楚表明低置信度或部分匹配的响应，也不愿悄悄用一个伪装成正常答案的最佳猜测来替代。这对正向地理编码、逆地理编码和自动补全最为重要，恰恰是在这些端点上，部分或含糊的地址会诱使系统返回最接近的合理匹配，而不是承认输入没有被干净地解析。以正常结果呈现的最接近合理匹配，是错误位置数据最有可能被嵌入货运、服务区域检查或客户记录的途径，因为响应中没有任何信息表明存在不确定性。
这也是我们刻意谨慎、不为地理编码和自动补全宣称具体的、经过验证的准确率数字，也不断言这些功能已经完全完成并得到验证的部分原因。一个有足够信心公布具体准确率数字的系统，必须对该数字未覆盖的输入会发生什么同样有信心，而对于任何地理编码系统，诚实的答案都包括一部分地址应该以未解析或含糊的结果返回，而不是被硬塞进一个答案里。
错误响应在当下是有代价的：它要求调用方应用处理失败情况，而不是总能拿到一个干净的对象，表面上这可能让开发者体验显得更差，因为一个碰巧正确的猜测看起来与无错误的响应完全相同，而一个碰巧错误的猜测看起来也完全相同，直到下游有人注意到。这恰恰就是问题所在。从外部看，猜测与正确答案无法区分，这正是为什么一个在内部无法分辨两者的系统，不应该通过挑选其中一个并当作确定答案来掩盖这个缺口。
我们认为，这种偏好（清晰的失败胜过自信的猜测）应该是对任何数据 API 的基本期望，而不仅仅是对我们。调用方可以围绕一个如实说明自己不知道什么的系统构建真正的错误处理。没有任何调用方能围绕一个总会回答的系统构建可靠的错误处理，因为无法区分它真正答对的请求和它悄悄猜测、恰好猜错的请求。