【51CTO.com快译】您想通过五个简单的步骤，来快速地在任意基于终端的环境(如：IBM i、VT、HPE NonStop、以及IBM Z)中构建API吗?如果您供职于某个大型组织的IT部门，那么此类需求您一定不陌生。毕竟，针对某些工作流程和功能，您所在的部门可能需要支持那些老旧的、基于终端的应用程序。
显然，上述情况给您带来的最大挑战主要是：时间。您需要花时间去确定供应商是否提供了新版应用程序的API，需要估算测试该版本的时间，以及将其部署到生产环境中所需的时间。同时，如果供应商没有提供对应的API版本，那么您就需要花时间来确定其源代码是否可用，或者花时间研究、并发现最优的集成点。可以毫不夸张地说：面对API的交付日期，时间永远是不够用的。您也许会问：该如何争取时间呢?
既然我们无法神奇地增加工时，那么就只能想办法去节省创建API的时间。下面我们来具体看看该如何构建基于终端应用的API：
第1步：定义API的接口
其实，定义API并不复杂，但是我们需要在开始编写代码之前进行仔细的考虑，特别是在命名和各种数据类型的模型方面。此事不可操之过急。一旦某个API被发布、并且可供调用，那么我们就无法在保证不破坏那些使用该API应用的前提下，轻易地更改其接口了。因此，在大多数情况下，我们需要将其与终端类应用中功能性的输入和输出相匹配：
第2步：使用录屏或机器人流程自动化(RPA)工具实现API
为了以更快捷、更简单的方法，发布基于终端应用的功能性API，我们可以模仿应用程序用户的各种行为。此举的好处在于：应用专家可以据此确证(validate)和验证(verify)您所记录的步骤，进而发现各种异常，以及潜在的错误。
由于API的定义主要源于终端应用功能的实际输入和输出，因此录屏工具的使用能够有效地降低API的实现难度：
第3步：寻找API的优化方法
在发布了API之前，您应该花费一些时间去研究其实现的有效方法。由于响应时间是至关重要的，因此，我们通常可以通过两种选择来加快API的执行速度。第一种选择是调查那些绕过终端显示，而直接调用应用程序的业务逻辑。另一种是尝试着去访问应用程序存储系统(如：数据库)中的数据。如下图所示：由于该应用程序公布了一个名为“GetCustByNr”的可调用程序，因此我们可以直接调用它的业务逻辑，以获悉其运行的时间。
第4步：更新API的实现
在此，我们假设：通过测试，发现了直接调用应用程序的业务逻辑，要比录屏工具的实现快一些。那么，我们在切换到该实现方式之前，还需要考虑以下方面：
1. 由于最终业务逻辑过程的界面可能会与您在第1步中定义的界面有所不同，因此您可能需要进行一些字段的映射和类型的转换。例如，在本例中，CUSTNR被定义为普通的十进制(Zoned decimal)。而在第1步定义的API中，“数字”已经被定义为了“字符串”类型(我们这样定义的原因是需要一个类型转换的示例)。
2. 输入格式的确证。该步骤通常是在终端屏幕上被处理的，因此基本的业务逻辑过程可能会在正确性检查和错误处理方面有所欠缺。也就是说，您必须确保输入(和输出)的数据不但有效，并且可以被异常处理的程序所捕获。
3. 接着，我们要进行相应的测试。通常情况下，您可以同时采用上面提到的两种API执行方式。如果我们发现通过API的业务逻辑方式获得的结果，与基于用户终端屏幕的API结果有所不同，那么就需要进一步找到根本的原因。
第5步：监视应用程序的生命周期
如今，各种终端应用往往是通过API的相互调用，来实现自我构建和运行的。因此正如我们在第1步中强调过的：任何API接口的变更，都会影响到与之关联的应用程序。那么反之亦然。
我们需要通过持续监控目标应用的整个生命周期，以避免由于应用程序的细微更改，而导致某些API的可用性和准确性，进而影响到整个应用程序的构建。当然，您也可以通过一些标准化的解决方案，来协助管理和协调基础终端应用与相关API的变更联动关系，进而保证开发团队能够按照自己的步调进行创新，且不会中断现有的业务。
原文标题：API Strategy for Terminal-Based Applications，作者：Jeroen van Dun
【51CTO译稿，合作站点转载请注明原文译者和出处为51CTO.com】
