It only takes five steps to quickly build an API based on the terminal environment

【51CTO.com Quick Translation】Would you like to quickly build APIs in any terminal-based environment (such as IBM i, VT, HPE NonStop, and IBM Z) in five simple steps? If you work in the IT department of a large organization, you must be familiar with such requirements. After all, your department may need to support those old, terminal-based applications for certain workflows and functions.

Obviously, the biggest challenge brought to you by the above situation is mainly: time. You need to spend time to determine whether the vendor provides the API of the new version of the application, and you need to estimate the time to test the version and the time required to deploy it to the production environment. At the same time, if the vendor does not provide the corresponding API version, then you need to spend time to determine whether its source code is available, or spend time to study and find the best integration point. It is no exaggeration to say that when facing the delivery date of the API, time is never enough. You may ask: How can we buy time?

Since we can't magically increase working hours, we can only think of ways to save time creating APIs. Let's take a closer look at how to build an API based on terminal applications:

Step 1: Define the API interface

Defining an API is not complicated, but we need to think carefully before we start writing code, especially in terms of naming and models of various data types. Don't rush this. Once an API is published and available for use, we can't easily change its interface without breaking applications that use it. Therefore, in most cases, we need to match it with the functional inputs and outputs of the terminal application:

Step 2: Implement API using screen recording or robotic process automation (RPA) tools

In order to release functional APIs based on terminal applications in a faster and simpler way, we can simulate various behaviors of application users. The benefit of this is that application experts can validate and verify the steps you record and find various anomalies and potential errors.

Since the definition of API mainly comes from the actual input and output of terminal application functions, the use of screen recording tools can effectively reduce the difficulty of API implementation:

Step 3: Find ways to optimize your API

Before publishing an API, you should spend some time researching effective methods for its implementation. Since response time is critical, there are usually two options to speed up the execution of the API. The first option is to investigate those business logics that bypass the terminal display and call the application directly. The other is to try to access data in the application storage system (such as a database). As shown in the following figure: Since the application publishes a callable procedure named "GetCustByNr", we can directly call its business logic to find out its running time.

Step 4: Update the API implementation

Here, we assume that through testing, we found that directly calling the business logic of the application is faster than the implementation of the screen recording tool. So, before switching to this implementation method, we need to consider the following aspects:

1. Since the interface of the final business logic process may be different from the interface you defined in step 1, you may need to do some field mapping and type conversion. For example, in this example, CUSTNR is defined as a normal decimal (Zoned decimal). In the API defined in step 1, "number" has been defined as a "string" type (the reason we define it this way is to need an example of type conversion).

2. Verify the input format. This step is usually processed on the terminal screen, so the basic business logic process may lack correctness checking and error handling. In other words, you must ensure that the input (and output) data is not only valid, but can be captured by the exception handling program.

3. Next, we need to conduct corresponding tests. Usually, you can use both of the above mentioned API execution methods at the same time. If we find that the results obtained through the API business logic method are different from the API results based on the user terminal screen, then we need to further find the root cause.

Step 5: Monitor the application lifecycle

Nowadays, various terminal applications are often self-built and run through API calls. Therefore, as we emphasized in step 1: any change in the API interface will affect the application associated with it. And vice versa.

We need to continuously monitor the entire life cycle of the target application to avoid minor changes in the application that may affect the availability and accuracy of certain APIs, thereby affecting the construction of the entire application. Of course, you can also use some standardized solutions to help manage and coordinate the linkage relationship between basic terminal applications and related API changes, thereby ensuring that the development team can innovate at their own pace without interrupting existing business.

Original title: API Strategy for Terminal-Based Applications, author: Jeroen van Dun

[Translated by 51CTO. Please indicate the original translator and source as 51CTO.com when reprinting on partner sites]