永不过期的 API 密钥带来的问题
一个多年前签发、从未轮换、至今仍然有效的密钥并不是一种便利。它是一个多年来没有人真正检查过的隐患。
反对为基本身份验证方式额外收费的理由
身份验证是使用 API 时比较平淡无奇的部分之一，而恰恰是这种平淡的细节，比应有的更频繁地被锁在某个价格档位之后。有些服务商把某些身份验证方式（HTTP Basic 认证或 Bearer 令牌模式）保留给付费更高的档位，而较低档位只支持某一种特定的请求头格式。验证一种身份验证方式与另一种之间的技术成本差异几乎为零。真正不同的是，每种方式对某位客户现有代码的便利程度，而这与他们使用 API 本身应该付多少钱毫无关系。
我们接受以 X-API-Key 请求头、Authorization Bearer 请求头、以密钥作为用户名的 HTTP Basic 认证或查询参数的方式传递密钥，适用于每一个主机，且任何一种方式都不额外收费。无论哪种模式已经契合您现有的代码，无论您的团队在其他 API 上已经在使用什么库或内部约定，都很可能已经得到支持，无需仅仅为了迁就我们碰巧偏好的某种格式而重构任何东西。
按档位限制身份验证方式，其背后的理由其实与成本无关，而是为了区分档位而区分档位：寻找可以留给高付费客户的功能，哪怕这些功能提供起来并无额外成本，只因为把更多功能锁在更高档位之后，能让更高档位在对比表上显得更有价值。身份验证方式很容易成为这种做法的目标，因为同时支持多种方式对服务商来说确实省力，对客户来说确实方便，这就使得对其加以限制纯粹是一个变现决策，而不是基于任何真实的成本差异。
我们认为，这种限制在无形中惩罚了开发者，而原因与他们从实际数据中获得多少价值毫无关系。一个现有工具默认使用 Bearer 令牌的团队，不应比一个工具默认使用自定义请求头的团队付更多的钱，因为两个团队发出的是完全相同的查询，得到的也是完全相同的答案。产品的价值在于响应。身份验证方式只是管道，而管道不应该根据哪根管子恰好适合您现有的墙而标上价格。
这里有一个更宽泛的原则，不仅适用于身份验证：对服务商而言提供起来没有额外成本的功能，不应仅仅因为可以这样做就被变成人为的档位界限。围绕真实成本差异（例如请求量）构建的档位结构是站得住脚的。而用低成本的便利功能来填充、并把它们留给高付费者的档位结构，主要是为了让价格页面看起来比底层产品实际上更有差异化。