【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】