速率限制应该写在文档里，而不是靠用户自己去发现
在生产环境中通过 429 错误才发现您的速率限制，这不是文档。这是一张本来就不应该需要存在的支持工单。
博客主题
我们的观点 （第 5 页）
关于位置数据行业的观点：定价、锁定、隐私，以及大型服务商做错了什么。
为什么我们按项目而不是按调用计算批量请求
一次包含一千个地址的批量调用仍然会执行一千次独立的查询。把它算作一次请求，只会掩盖真实用量的去向。
反对专有响应格式的理由
专有的字段名或自定义的对象模型不会为服务商节省任何成本，却会让客户日后不得不重写代码。朴素、可预测的 JSON 并不是缺失的功能。
为什么我们构建了无密钥层级，而不是延长试用期
试用期会按固定时间表结束并要求提供信用卡。无密钥层级则会一直正常工作。我们认为后者更尊重开发者的时间。
按产品计费在 API 的实际使用方式上错在哪里
真实的应用会在同一条请求路径中混合使用地理编码、IP 查询和时区调用。把它们作为独立的产品计费，忽视了它们被一起使用的方式。
开放的时区数据不应该是付费功能
时区查询依赖一个公开且持续维护的数据源。为这项查询单独收取额外费用，并不反映任何真实的额外成本。
为什么兼容主机比新的 SDK 更重要
SDK 要求您在项目的整个生命周期内信任某一家公司的客户端库。兼容主机只要求您修改一行配置。
悄悄名不副实的“无限”方案带来的问题
“无限”本应意味着没有上限。仔细阅读许多所谓无限的 API 方案的细则，您往往会发现一条合理使用政策，悄悄地表明事实并非如此。
为什么我们按请求而不是按席位定价
按请求定价与 API 的实际运行成本相符。按席位定价衡量的是人数，而不是用量，而地理编码流量很少与这两者中的任何一个成正比。
仅我们的观点分类，发布即推送。
订阅我们的观点分类