防止你的 API 被人采用的 4 个技巧

| 2021-07-17

过去几个月里，我一直在对付一个流行健身品牌的 API，最后发现自己陷入了一种卡夫卡式的噩梦。程序员都喜欢挑战，优秀的程序员一定要征服种种挑战。我一直觉得自己是一个非常优秀的程序员。因此，尽管每天晚上我都以失败告终，只能上床睡觉，但我内心深处的某些东西是不会让我就此放弃的——第二天早上，我会带着新的想法和新的动力满血复活。

这样的循环已经持续几个月，这就像一场梦，日复一日，迟迟没有苏醒的一刻。我要处理的任务很简单：获取数据，保存数据，完事。但面对这个 API，我被一堆脆弱的代码团团围住，追逐着那些我永远都抓不到的错误。

那么，怎样才能构建一个具备如此高技术障碍的 API，让你可以击败一个拥有 20 年经验，过去总有办法走出困境的老手呢？你如何让他慢慢抓狂，并让他从自己所热爱的这一职业中获得的所有快乐一扫而空呢。好吧，我会告诉你诀窍的。

我们先来布置角斗场地。

对于授权需求，我们将使用 OAuth1a。当然，这是一个非常好的标准，但用它签署请求会增加那么一点点复杂性，让你永远没法搞清楚原来是签署导致请求失败的。

服务器到服务器的通信

我们不会响应你的 API 请求，而是给你回电。你请求服务器提供一些数据，然后在从现在到宇宙终结之前（或永远不会）的某个时间点上，我们会做出回应。响应一般需要几毫秒，但有时需要几分钟，在极少数情况下需要几个小时。但最重要的是，如果我们没有任何数据，我们根本就不会做出响应。不一致是程序员的天敌。

这种设置在实践中意味着什么呢？这意味着你需要在服务器或代理后面设置一个端点。这也意味着在你的单元测试中，如果没有响应，那么你将不得不做一些工作。你得编写一些代码，对其进行测试，如果失败还要检查你的 web 服务器日志。

但是，也许在你查看请求通过的那些日志时，它终于有反应了，只不过响应来得慢一些。不过当然 JSON 没有按照你预期的方式格式化，所以请重来一遍吧。

禁止重复数据

这招可是很不错的。不管你请求任何数据，你都只能请求恰好一次。不是一分钟一次，也不是一小时或一天一次——是这辈子都只能请求那么一次。这实际上意味着任何单元测试都是不可重复的，想要重来一次？请手动注册新帐户并在里面人工填好数据。

假设当代码生效时，一位用户请求了某个时间段内的数据，他要的数据可能存在也可能不存在，你可能会，也可能不会收到这些数据，但你仍然需要跟踪这一请求，因为如果你这个请求只重叠了那么区区一天，那么在将来某个时候，你就会收到一条错误消息。当生产环境中的请求失败时会发生什么呢？当然没有缓解措施，你什么都做不了。这些数据是不可恢复的——永远别指望它能恢复了。

我可以用一整天谈论这个技巧的强大力量。不过你只要简单地想象一下，比如你编写了自己的第一行代码，然后又成功地执行了它，然后当你再次运行它时，它就没有任何反应了。想象一下项目的其他部分全变成了这个样子，那会是多么壮观的场面。

开发和 QA 速率限制

我想你可能会争辩说，将 QA 速率限制设置为远低于生产环境的速率可能是有原因的。但如果将阈值设置为每分钟 100 天的数据（不是请求）会有什么样的结果呢？这个技巧特别狡猾。

首先，它的确为你的开发测试周期设置了一个最大阈值。你可以写一些代码，运行一个测试，然后开始等待。但它的要点在于它加入了另一个因素，让代码可能会莫名其妙地失败。

最厉害的是当你正在尝试开发一个高度可扩展的应用程序的时候，你到底该怎么开始测试随便什么类型的负载呢？简单的答案是你可以在生产环境中进行测试，也可以根本不做任何测试。

PROD 中的应用程序级别速率限制

应用程序级速率限制这个技巧的美妙之处在于，你需要一个消息队列才行。当然可能还有其他技巧，但如果它是一个 Web 应用，并且你不想让一堆长时间运行的线程在队列中运行，那么这几乎是你唯一的选择。

当然，它们也加入了其他一些东西，但这些几乎不值得一提，因为这些东西只不过是典型的数据结构挑战或糟糕的参数化选项而已。这些是你平日里经常要面对的挑战，并不是那些即便是最有经验的开发人员也会屈服的挑战。

在过去的几个月里，我花了很多时间试图想象这个 API 背后的团队究竟是什么样子的，以及他们到底有什么样的动机来开发这样一个 API。无论你是如何看待它的，他们的初衷肯定是防止别人使用这个 API。也许，他们正在与一个其基础设施拥有数十年历史的系统交互，这一系统会因最轻微的干扰而崩溃。也许他们有很多新招来的开发人员，编写了一些非常低效的代码，而当他们探讨解决方案的时候，最后想出来的办法就是尽可能给用户设置更多障碍？或者也许他们只是丝毫没有同理心。也许当他们权衡设计决策时，可用性这一条的评分被减到了零，这样其他所有问题就都能得到最大程度的重视了。

但我认为还有另一种可能。公司都喜欢把他们的花园围起来，但在健身领域，数据可移植性是一个卖点。那么，你如何才能同时实现两者呢？你如何才能一边把你的花园圈起来，与此同时给大家指出大门的位置呢？如果是因为这样的理由，这个开发噩梦就完全可以解释清楚了。在这种情况下，认真努力地尝试编写代码来使用它的用户就是唯一的傻瓜。

原文链接：

https://chrislukic.com/2021/06/16/techniques-to-prevent-adoption-of-your-api/

本文文字及图片出自 InfoQ

本文文字及图片出自