永不过期的 API 密钥带来的问题
一个多年前签发、从未轮换、至今仍然有效的密钥并不是一种便利。它是一个多年来没有人真正检查过的隐患。
按产品计费在 API 的实际使用方式上错在哪里
打开几乎任何一个使用位置数据的应用的请求日志，您都不会看到某一种查询在孤立地运行。一个注册表单会对地址进行地理编码，检查 IP 以获得大致的网络匹配，并给记录打上时区标记，这一切都在同样的几百毫秒内完成。这不是碰巧共用同一家 API 服务商的三个独立使用场景。这是一个涉及三类数据的工作流。
按产品计费却假装并非如此。它把地理编码定在一个档位，把 IP 查询定在另一个档位，把时区或海拔数据作为各自单独收费的可选附加项，仿佛一家需要其中一项的公司不太可能需要其他几项。实际上恰恰相反：需要其中一项，通常意味着您至少还需要另一项。一个对收货地址进行地理编码的电商结账流程，几乎肯定还想知道应该按哪个时区安排配送时段。一个查看 IP 地址的欺诈检查，通常也想把它与存档的地址进行交叉比对。
我们把 My Geocode 定价为一个产品、一个费率。每个端点（地理编码、IP 查询、时区、海拔、邮政编码）以及每个兼容主机，每次请求的费用都完全相同。没有需要核对的单独价目表，也没有在您已经为地理编码档位付费之后才加上时区数据的档位。请求就是请求，无论它访问的是哪个端点。
这不仅仅是为了让客户安心。它反映了底层工作实际上是如何进行的。在大多数应用运行的规模下，对一个端点的查询与对另一个端点的查询相比，服务成本并没有天差地别。把它们拆分成价格各异的独立产品，追踪的并不是回答请求的成本上的真实差异。它追踪的是服务商能在账单上列出多少个单独的项目。
按产品计费还会让您更难理清自己的用量。如果地理编码按一种方式计费，IP 查询按另一种方式计费，那么估算下个月的账单就意味着要对照两套费率结构跟踪两个计数器，并祈祷调用组合不会发生变化，导致总额出现不可预测的改变。统一的固定费率把这种估算简化为一个数字：总请求数乘以一个价格。任何为自己的集成做预算的人，都可以在信封背面算出这笔账。
按产品定价还深藏着一个我们认为完全错误的假设：不同类型的位置数据服务于不同的客户。根据我们的经验，它们服务的是同一位客户，只是处于同一个请求的不同环节。物流平台、注册流程和欺诈系统，都会把地理编码、IP 和时区数据拼接在一起，用于做出一个决策。假装这些是不同市场的定价方式，迫使客户要么为一个使用不均衡的套装多付钱，要么为了避免这一点而同时周旋于多家供应商之间。一个费率、一份端点列表，是更简单也更诚实的答案。