【.com快译】你想在任何基于终端的环境（如：IBMi、VT、HPENonStop、和IBMZ）快速构建API)构建API？如果你在大型组织的IT部门工作，你一定熟悉这样的要求。毕竟，您的部门可能需要为某些工作流和功能支持传统的、基于终端的应用程序。显然，上述情况给你带来的最大挑战主要是一个：时间。您需要花时间确定供应商是否为应用程序的新版本提供API，估计测试该版本需要多长时间，以及将其部署到生产中需要多长时间。同时，如果供应商没有提供相应的API版本，那么你就需要花时间去判断它的源代码是否可用，或者花时间去研究发现最佳的集成点。毫不夸张地说：面对API的交期，时间永远不够用。你可能会问：你如何争取时间？既然我们不能神奇地增加工时，我们只能想方设法节省创建API的时间。我们来看看如何基于终端应用程序构建API：图1：终端应用程序中的客户搜索功能第一步：定义API的接口其实定义一个API并不复杂，但我们需要开始编写代码要仔细考虑，尤其是在各种数据类型的命名和建模方面。这件事急不得。一旦API发布并可供调用，我们就无法在不破坏使用该API的应用程序的情况下轻松更改其接口。因此，在大多数情况下，我们需要将其与终端类型应用程序中的功能输入和输出相匹配：图2：定义接口Step2：使用屏幕录制或机器人过程自动化(RPA)工具来实现API，以便基于终端应用程序发布功能API的一种更快更简单的方式，我们可以模仿应用程序用户的各种行为。这样做的好处是应用专家可以验证和验证你记录的步骤，然后发现各种异常和潜在的错误。图3：录屏工具示例由于API的定义主要来源于终端应用功能的实际输入输出，因此使用录屏工具可以有效降低API的实现难度：图4：使用屏幕录制工具实现第一个API第3步：寻找优化API的方法在发布API之前，您应该花一些时间研究实现它的有效方法。由于响应时间很关键，我们通常有两个选项来加速API的执行。第一个选项是调查绕过终端显示并直接调用应用程序的业务逻辑。另一种是尝试访问应用存储系统（如：数据库）中的数据。如下图所示：由于应用程序公开了一个名为“GetCustByNr”的可调用对象，我们可以直接调用其业务逻辑来了解它何时运行。图5：描述可调用模块“GetCustByNBr”的PCML文件第四步：更新API的实现这里，我们假设通过测试发现直接调用应用程序的业务逻辑比屏幕录制的实现更快工具。那么，在切换到这种实现方式之前，我们需要考虑以下几个方面：1、由于最终业务逻辑流程的接口可能与你在步骤1中定义的接口不同，你可能需要配置一些字段的Mapping和类型转换。例如，在本例中，CUSTNR被定义为普通小数（Zoneddecimal）。在步骤1定义的API中，“number”已经被定义为“string”类型（之所以这样定义，是因为需要一个类型转换的例子）。图6：将“number”定义为“string”，将“CUSTNR”定义为decimal的映射图7：从“GetCustByNbr”的输出字段到API定义的映射2.输入格式的确认。此步骤通常在终端屏幕上处理，因此底层业务逻辑过程可能缺乏健全性检查和错误处理。换句话说，您必须确保输入（和输出）数据不仅有效，而且还被异常处理程序捕获。图8：使用可调用程序验证API的实现3.接下来，我们需要进行相应的测试。通常，您可以使用上述两种API执行方法。如果我们发现通过API的业务逻辑得到的结果与基于用户终端屏幕的API结果不一样，那么我们就需要进一步查找根本原因。图9：确保API行为在两种执行方法运行后具有相似的结果。第五步：应用生命周期监控如今，各种终端应用往往通过API相互调用，实现自身的构建和运行。因此，正如我们在步骤1中强调的那样：对API接口的任何更改都会影响关联的应用程序。然后反之亦然。我们需要对目标应用的整个生命周期进行持续的监控，避免因为应用的微小改动导致部分API的可用性和准确性，进而影响整个应用的构建。当然，也可以通过一些标准化的解决方案来帮助管理和协调基础终端应用和相关API之间的变更联动关系，从而保证开发团队在不中断现有业务的情况下，按照自己的节奏进行创新。原标题：APIStrategyforTerminal-BasedApplications，作者：JeroenvanDun
