永不过期的 API 密钥带来的问题
一个多年前签发、从未轮换、至今仍然有效的密钥并不是一种便利。它是一个多年来没有人真正检查过的隐患。
为什么只支持 webhook 的 API 会悄悄地把批量用户排除在外
对于您无法预测发生时间的事件，Webhook 是合理的：一笔付款完成清算、一批货物的状态发生变化，或者服务商一侧发生了某件事，您的系统需要在它发生时做出反应。对于您直接提出并期待直接回答的问题，比如解析一个地址或查询一个时区，把 Webhook 作为获取答案的唯一方式就不那么合理了。仅仅为了接收一次同步查询的结果就要求提供 Webhook 端点，会把真实的基础设施工作推给一个可能只想运行脚本、等待响应然后继续的客户。
对于批量和大批量用例，这个问题尤其突出。一个运行一次性脚本、从电子表格中解析一列地址的开发者，并不想搭建 Webhook 接收端、在其端点短暂无法访问时处理重试，还要把收到的 Webhook 负载与原始请求一一对应，而这一切只是为了得到本可以直接在发起调用的响应中返回的答案。对这类任务仅采用 Webhook 交付，会给一个本应只是一次请求和一次响应的任务增加一整层基础设施。
我们默认把查询（包括批量和大批量查询）视为同步的：您发送请求，直接拿回答案，无论该请求包含一个条目还是一千个。使用批量端点并不需要为了收集结果而搭建面向公网的接收端。脚本、cron 任务或一次性的命令行工具都可以调用该端点并立即使用响应，就像单次查询一样。
仅支持 Webhook 的设计往往源于一种围绕服务商一侧异步处理构建的架构，在这种架构中，大型批处理任务在内部确实需要相当长的时间才能完成，而 Webhook 确实是通知完成的更自然方式。对于某些大规模或大量排队的处理来说，这是一种正当的模式。当它成为唯一提供的选项时，问题就出现了，它迫使每一种用例，包括那些宁愿稍等片刻直接得到答案的用例，都进入一个为另一种更慢的工作负载设计的架构。
我们并不反对把 Webhook 作为真正长时间运行或异步工作的一个选项。我们反对的是把它强加于根本不需要异步的任务。一个想发送一千次查询并拿回一千个答案的脚本，应该能够恰好做到这一点，一次调用、一次响应，而无需先搭建基础设施来接收一个回调，而这个任务用同步请求同样能处理好，所需的代码还少得多。