“实时”位置数据究竟需要什么
“实时”常被当作“快速”的同义词。它真正应该表达的意思是，答案反映的是世界的当前状态，而不是上个季度的快照。
标签
#API 设计
我们如何处理空结果和低置信度结果
当一个查询确实无法可靠解析时，什么都不返回比返回一个伪装成事实的猜测要好。以下是这一选择背后的理由。
为什么海拔数据总被当作事后才考虑的东西
海拔数据很少在价格页面上单独列出，而这种缺席真实地反映了它在实际构建时受到多少重视。
反对为基本身份验证方式额外收费的理由
请求头、Bearer 令牌和查询参数对请求进行身份验证的方式完全相同。为其中某一种多收费，是在为偏好收费，而不是为功能收费。
切换服务商时可能遇到的速率限制差异
各服务商的速率限制不仅数值不同，结构也不同。在认定您现有的逻辑仍然适用之前，请先检查以下几点。
为什么我们宁愿返回错误，也不愿给出错误的猜测
看起来很自信的错误答案比坦诚的失败更糟糕。错误会提醒您去检查某些东西。自信的错误猜测却告诉您一切正常。
迁移服务器端集成而不改动客户端
服务器端的地理编码迁移往往可以让依赖它的客户端应用完全察觉不到。下面介绍如何按这种方式来设计。
为什么按国家划分价格层级是个坏主意
在一个国家查询地址比在另一个国家收费更高，是把地理本身当作定价杠杆，而不是当作需要提供的普通数据。
为什么应该把邮政编码查询视为一等公民
一个在定价和文档上被当作附属品的邮政编码端点，在构建时也会被当作附属品。认真对待它，要从平等对待它开始。
这个行业在 IPv6 普及上仍然犯的错误
一个仍然把 IPv6 当作次要边界情况的 IP 查询 API，实际上是在悄悄地把越来越大比例的真实互联网流量当作事后才考虑的东西。
为什么账户级和网络级配额都应该存在
账户级配额追踪的是您是谁。网络级配额追踪的是您的流量实际来自哪里。一个严肃的系统两者都需要。
所有端点统一采用更清晰的错误格式
现在每个端点都以统一、一致的格式返回错误，让失败更容易被检测、记录和以编程方式处理。
为什么只支持 webhook 的 API 会悄悄地把批量用户排除在外
webhook 适合一次处理一个请求。对于只想发送一千次查询并等待一千个答案的脚本来说，它就很不合适。
为什么我们公开错误代码，而不是把它们藏起来
没有文档说明的错误代码会让每一次失败的请求都变成猜谜游戏。公开错误代码列表是一件小事，却能节省实实在在的调试时间。
为什么批量定价应该与单次请求定价一致
逐一发送的一千次查询和作为批量发送的一千次查询，工作量是相同的。价格不应该取决于它们是如何打包的。
为什么 API 版本管理应该乏味而稳定
一个令人兴奋的新 API 版本，对其下游的每个人来说都是一个迁移项目。乏味而稳定的版本管理是一项功能，而不是缺乏雄心。
为什么我们没有先构建浏览器 SDK
为服务器端查询提供的浏览器 SDK，主要作用只是把您的 API 密钥挪到访客浏览器能看到的地方。这不是值得拥有的便利。
网络级速率限制能解决哪些按密钥限制无法解决的问题
仅按密钥限制，就是假设一个密钥代表一个用户。按网络进行速率限制，堵住了这一假设悄然失效时出现的漏洞。
邮政编码值得比现在更多的重视
邮政编码查询常被当作地理编码旁边一个次要的实用工具，但它具有真实的结构和真实的地区差异，值得同样用心对待。
为什么文档质量比功能数量更重要
一个您搞不清楚如何使用的功能，跟不存在没什么两样。文档不是支持成本，而是产品本身的一部分。
供应商锁定的隐性成本
锁定很少表现为某一个错误的决定。它表现为上百个小决定，悄悄地让离开的代价远远高于原地不动。
速率限制应该写在文档里，而不是靠用户自己去发现
在生产环境中通过 429 错误才发现您的速率限制，这不是文档。这是一张本来就不应该需要存在的支持工单。
为什么我们按项目而不是按调用计算批量请求
一次包含一千个地址的批量调用仍然会执行一千次独立的查询。把它算作一次请求，只会掩盖真实用量的去向。
反对专有响应格式的理由
专有的字段名或自定义的对象模型不会为服务商节省任何成本，却会让客户日后不得不重写代码。朴素、可预测的 JSON 并不是缺失的功能。
按产品计费在 API 的实际使用方式上错在哪里
真实的应用会在同一条请求路径中混合使用地理编码、IP 查询和时区调用。把它们作为独立的产品计费，忽视了它们被一起使用的方式。
开放的时区数据不应该是付费功能
时区查询依赖一个公开且持续维护的数据源。为这项查询单独收取额外费用，并不反映任何真实的额外成本。
为什么兼容主机比新的 SDK 更重要
SDK 要求您在项目的整个生命周期内信任某一家公司的客户端库。兼容主机只要求您修改一行配置。
为什么我们按请求而不是按席位定价
按请求定价与 API 的实际运行成本相符。按席位定价衡量的是人数，而不是用量，而地理编码流量很少与这两者中的任何一个成正比。