十年前，可能只有一个应用程序直接与数据库对话并输出 HTML；客户服务、销售——与我合作的大多数组织都在朝着更像 unix 的设计理念发展，其中每个应用程序都由一系列缝合在一起的小工具组成。在上面的网络示例中，这可能意味着登录服务与调用其他服务的网页相结合——比如输入和更新记录。这允许客户服务团队使用 Web、命令行、预定或任何其他界面编写自己的工具。
听起来好得令人难以置信，不是吗？这是事实，但这是有代价的。例如，我从未定义过一种机制来管理在这种方法下会导致的 API 激增。考虑一下：不受控制的生长是癌症的一种定义。
由于 API 的快速创建并不是那么致命，我将其称为 API 蔓延；我在每个转向 Web 服务方法的客户中都看到过这种情况，通常在转换后两到四年。
今天，我将告诉您如何控制它、避免它，或者，如果必须的话，驯服 API 蔓延。
从一团糟开始
Web 服务备受吹捧的优势之一是可重用性。我们调用 coverage_loopup(date, memberId) 函数，而不是直接在 SQL 中重写查找以查明成员是否有覆盖。我们不是用一种编程语言编写它，而是通过网络公开它，这样任何编程语言都可以找到它。
到目前为止一切都很棒。
可悲的是，为了使用这个功能，我们需要找到它。没有控件，组织的 Web 服务开始感觉有点像垃圾抽屉。首先，我们必须去寻找我们要找的东西，要么与团队交谈，要么通过内部网页搜索。然后，最终，我们找到了三个几乎可以满足我们要求的工具（我们需要知道药房的保险范围，或者用户是否达到了他们的免赔额，或者其他一些细节）。现有的服务并不能真正工作，所以我们写了第四个服务，must_pay(date, memberid, coverage_type)。
在经历了几次这种麻烦之后，我们创建了三个新服务。完全重用这些服务的整个概念变得可疑。
这个循环帮助我们更有效地摧毁下一个好心人的精神，他们乐观地认为 一定有人已经建造了这个 …… 。
让我们修复它
驯服这种 API 蔓延当然意味着将服务放在程序员可以找到它们的地方，但我要小心。闪亮的退出承诺让我们陷入了困境；闪亮的新服务存储库和群发电子邮件不足以让我们离开。
这样想：世界上最精心策划的图书馆，里面有写得糟糕、未经编辑的小说，简直就是个笑话；它几乎不会为其社区提供任何实用价值。你不能认为“ 如果我们建造它，他们就会来 ”。是的，你必须建造它，但 如果他们不 信任它，他们就会远离 。
服务目录
在互联网出现之前，我们有黄页——一本旨在让人们可以找到电话号码和服务地址的书。电话簿对所有使用它的人免费，由服务广告商付费。如果广告商无法被发现，那么他们就不会为广告付费，黄页也不会盈利。
这意味着黄页的首要问题是让人们通过主题或名称找到他们需要的东西。公司服务目录应该做同样的事情——让服务可被发现，并使注册和更改过程不会过于痛苦。您可能会找到一个团队成员，在遇到这种挑战时，他们的眼睛会发光——寻找最适合工作的工具的想法。
你也可能在这一切上投入时间、精力和金钱，回顾两年后，发现并没有太大变化。如果不提高构建和使用 API 的人员之间的信任，您会发现自己在原地打转，寻找处理这种情况的方法，您甚至可能需要再次阅读本文。
除了设置服务存储库并将其发布到您的团队之外，控制您的 API 还涉及改进纪律、相当多的吃力不讨好的工作和相当大的耐心。这意味着消除服务之间的重复，通过更好、更一致的命名使这些 API 自我记录。需要记录并在某些情况下对每项服务的合同进行逆向工程。这必须发生，不是因为某种抽象的“对”和“错”，而是为了解决 API 在你脚下蔓延的关键原因：人们只是不信任这些服务，以至于不会冒险冒险他们的项目在他们。
什么建立信任？
建立和维护信任的主题填满了书架，而不仅仅是一本书。您可能需要阅读其中一些书籍，但不要绝望：我今天可以为您提供一个起点。根据经验，您可以通过 向程序员提供服务来满足他们的需求并发挥作用，从而 开始赢得程序员的信任。可能仍然存在更深层次的信任问题，但如果你能做到这一点，那么你就会走得更远。好消息：这为您提供了一条通向成功大方向的清晰路径。坏消息：这涉及一些令人沮丧的工作。你需要相信你的团队正在遭受蔓延的困扰，足以值得解决这个问题，并相信我的建议会有所帮助。 （看到了吗？信任问题无处不在。你真的应该看看那些书。）
这些服务本身需要工作，因为如果他们不工作，那么我就不能依赖他们。遗憾的是，“it works”被列为英语中最含糊不清的句子之一，所以让我澄清一下我的意思：服务需要做他们声称做的事情。这几乎肯定意味着可执行示例——有些人可能称之为集成测试。我将“它有效”定义为“通过这些测试”。换句话说，我根据服务通过的测试来定义“服务做什么”。
现在添加测试
当我想使用现有代码但我不确定它的作用时，我首先为它自己编写测试。我这样做是为了挑战我对它的行为方式的假设。当其中一项测试通过时，我想 啊哈！我对它的作用是正确的！ 当其中一个测试失败时，我想知道 服务是否中断，或者我是否对它应该做什么做出了不合理的假设？ 随着示例集合的增长，我对服务的理解也在增长。从这个不断增长的测试套件中，我可以猜测该服务在类似情况下可能会做什么，从而帮助我编写更全面、更可靠的测试集。当我随后将此服务和示例发布到存储库中供其他人使用时，潜在客户可以更轻松地判断它是否会帮助他们解决问题，它会做什么，不会做什么，以及使用该服务是否需要比自己建造投资少。这一切都从编写测试开始。
所以写测试。不仅是在创建服务时，不仅是在为存储库记录服务时——即使团队使用服务时，他们也可以为其编写测试，留下他们所学知识、服务用例和预期结果的记录.如果您没有时间编写测试，那么至少记录您对服务功能的假设和期望。提供示例，即使您不能立即运行这些示例。 （通过编写示例，甚至作为文档中的要点，我们可以选择在有时间和精力时将它们变成运行测试。）使这些测试易于查找和运行。使这些示例易于查找和阅读。一遍又一遍地这样做，即使看起来没人在意。这说明了信任的关键点之一：在你开始从别人那里得到回报之前，你必须付出很多。
随着针对给定服务的测试套件的增长，我们对服务的信心也在增长，我们可以将其移动到其他人可以找到并开始使用它的地方。通过这种方式，我们使用一种内部开源的孵化器项目模型来提供声望，即已发布的服务存储库。在孵化器项目中，我们发现“尚未准备好迎接黄金时段”的服务。这些是我们正在缓慢但肯定地测试和记录的内容。也许我们正在重构它们以改进公共界面。也许我们正在逐步重写其中的一些（不要过火），打算发布新版本并逐步淘汰旧版本。随着时间的推移，我们将服务从这些孵化器转移到服务存储库中。这建立了更多的信任，因为它清楚地描述了我们认为哪些服务已经准备就绪，哪些需要更多工作。它充当我们 API 的一种 服务级别协议 ： 您应该期望这些 API 能够工作并且能够理解它们，但是那些那里的 API 仍 处于测试阶段。也许阿尔法。当心。我们 正在努力 。
这与我们在编程中所做的非常相似，当我们一次编写一些代码时，他们将其转换为供内部使用的方法，然后最终，我们犹豫了一下，将其添加到库中供其他程序员使用.
使用上面的策略，当服务被添加到存储库时，它是可发现的、记录的和有示例的。
这与我们的蔓延场景有点相反——我们正在避免诱惑，所以发布一个服务，直到我们确信它已经准备好迎接黄金时段。当你与程序员建立信任时，他们会慢慢地更宽容地接受你的错误，但这需要时间。你做的越仔细，你就会越早建立起系统维持自身所需的临界信任度。这一切都从编写测试开始。
让您的 API 流畅
请记住：如果人们不知道它的存在，找不到任何东西，并且仍然名声不佳，那么拥有世界上编写最好、编辑最仔细的书籍的图书馆就不会成功。是的，您需要一个服务存储库，但除此之外，您还需要修复一些已经因蔓延而遭受的损失。你需要重新获得他们的信任。我已经为您提供了一项关键技术，但您可能仍想更多地了解信任，而不仅仅是编写测试的有益效果。我知道您忙于处理 REST、SOAP、XML、JSON 和所有这些东西，但如果您不做有助于程序员 信任 这些 Web 服务的事情，那么您将重新阅读这篇文章两年了，想知道哪里出了问题。
将你阅读的下一本书写成关于信任的书，你会发现更容易控制这种蔓延。相信我。
去哪里寻找更多
小变化的技术方面常常使我们的目标变得更具适应性；缺乏信任会扼杀变革。这里有一些参考资料可以帮助您摆脱困境。
重构数据库 。这看起来很奇怪，但 API 的行为很像数据库模式，至少在难以更改的意义上如此。阅读这本书会给你一些关于如何处理不断变化的已发布 API 的想法。
团队的五个功能障碍 。更深入地了解信任在任何团队情况下的作用，包括但绝对不限于 API 蔓延。
信任的速度 。当您准备好深入了解信任作为组织成功的要素时，您可以从这里开始。
