我们的观点

为什么沙盒环境应该免费

有些 API 提供一个在功能上与生产环境分离的沙盒环境:不同的密钥,有时是不同的端点,偶尔还有自己的价格结构或更严格的限制。这样做的初衷是合理的,为开发者提供一个安全的空间进行测试,而不影响真实用量或真实计费。但在实践中,一个需要单独注册步骤、单独密钥或单独付费升级步骤的沙盒,恰恰在开发者试图判断您的 API 是否值得付出这些麻烦的那一刻,增加了麻烦。

我们不运行单独的沙盒。测试和生产使用同一份每天免费额度:任何地址每天 2,500 次请求,无需密钥;添加密钥后每天再增加 2,500 次,按网络计算。没有需要学习其独立限制的单独测试模式,也没有把认真测试挡在购买之后的付费层级。您在评估期间用来构建的系统,与您部署时所用的系统完全相同,免费额度也完全相同,而这一切都在您花出一欧元之前。

这很重要,因为一个表现与生产环境哪怕只有细微差别的沙盒,测试的是沙盒,而不是您的集成。如果单独的沙盒使用简化或虚假的响应数据而不是真实数据集,您只有在上线之后才会发现真实世界的数据怪癖,这就在很大程度上违背了测试本来要发现问题的初衷。用真实数据、使用真实的免费额度对真实系统进行测试,意味着您在评估期间了解到的情况,确实就是您在生产中运行时的情况。

不把沙盒访问挡在单独的付费步骤之后,对我们是有成本的:这些免费测试流量中会有一部分永远不会转化为付费账户,这与任何慷慨的免费层级是同样的取舍。我们认为这个成本是值得的,因为另一种做法恰恰把错误的激励施加在正在决定是否要基于您的 API 进行构建的开发者身上。付费或严格受限的测试模式,要求人们在还不知道产品是否适合自己的使用场景之前就做出财务承诺。一条免费且功能完整的测试途径,则让这个决定在真正试用之后,根据产品本身的优劣做出。

这并不意味着测试完全没有限制。覆盖轻度生产使用的每天 2,500 次请求同样覆盖测试,而针对这份额度进行的大规模负载测试,会触及小型生产集成同样会触及的上限。这是有意为之的。免费层级足够慷慨,可以进行真正的评估,但并非无限,把它当作高流量产品的永久测试环境,与用它来确认集成可以正常工作、然后再切换到付费使用,是两回事。

沙盒应当如实回答一个问题:使用真实的系统,它是否按我预期的方式工作。为这个答案收费,或者用真实系统以外的任何东西来回答它,无论哪种方式都违背了初衷。