工作流程与 API

今天我有一项工作给你。 我要你 — — 是的，就是你 — — 去银行存一张支票。 您必须上车，开车前往银行，进去与出纳员办理手续，然后回家。

生气了吗？ 你应该这样做，尤其是当你只需使用你的手机银行应用程序即可完成所有额外步骤而无需执行任何额外步骤时。

朋友们，这就是工作流程（过程）和 API 之间的区别。

有一种非常真实的东西（我编造了名字，但不是真的存在）叫做API 税。 这是使用单独的 API 调用执行复杂过程所产生的时间和技术债务。 这就像亲自去银行而不是使用移动应用程序进行存款一样。

随着流程的扩大，税收也会增加。 如果您有一个漫长的过程，需要十或二十个不同的 API 调用，那么代码（脚本也是代码）就会变得越来越复杂，这会影响故障排除并使得将来的更改更加困难。 通过单独的 API 调用来僵化流程与敏捷性相反。 脆弱性会冻结通过优化来提高效率的机会。

工作流基本上是针对常见执行任务的预定义流程。 大多数业务（甚至运营）流程都属于此类别。 它们是您用来登录、导航到系统正确部分、更改端口上的访问控制然后提交更改的命令。 每次做这个任务都是一样的。 这是一个常见的过程，并且可以轻松编纂。 运营中有很多这样的流程，通过将它们包装为工作流，我们不仅可以消除 API 税，还可以提高调用它们的脚本的质量和可持续性。

这是因为使用工作流而不是 API 意味着代码更简单、更易于管理和更易于更改。 它们更加敏捷，更加不易破碎。

考虑一下这个完全虚构的例子。 首先，您采用基于 API 的方法。 该流程中的每个步骤都代表一个 API 调用。 这意味着必须随着时间的推移开发、测试和维护包含近二十种不同调用的脚本。 这就是技术债务。 它与编写时所使用的系统的 API 版本相关。 如果其中一个调用发生变化，脚本也必须改变。

右侧有一个基于工作流程的方法。 您仍然可以通过 API 调用启动该过程（在许多组织中可能更可取），但该过程的实际步骤是根据初始调用发送的参数（变量）执行的。 您可能必须清理并提交，但是您仍然将所需的代码减少到两个或更少的交互。

这并不是说使用 API 和模板是一件坏事。 它不是。 但通常的情况是——特别是在网络世界中——使用 API 需要特定于系统和网络的一般知识。 这使得 DevOps 或开发人员难以使用 API。 工作流方法消除了对知识或专业知识的假设，这意味着 DevOps 可以轻松使用它们，而 NetOps 保留了工作安全。  

在自动化占据主导地位（甚至可能占据主导地位）的环境中，基于工作流的方法可以为 NetOps 提供实质性的缓解，因为 DevOps 无需大量领域特定知识即可调用任务。

嘿，他们还可以避免那些令人讨厌的 API 税。 那么谁不喜欢逃税呢？