Seamless-Data-Exchange
Blogs

Revolutionize Data Exchange on AS400 with RESTful APIs

By PIO TEAM on March 4, 2025

Are you.,

Still relying on your AS400 for mission-critical tasks?

It is time to.,

Connect your legacy system to the modern web with REST APIs!

In this guide, you will learn:

HTTP Webservice

If the web service uses an HTTPS connection, it communicates using SSL. SSL, or Secure Socket Layer, is a technology that enables the web service client and the remote web service server to exchange data over a secure connection. Data is encrypted before transmission and decrypted upon receipt for processing. This is a two-way process, meaning both the server and the client encrypt all traffic before sending data. A certificate is required for SSL communication.

Certificates

A public key certificate, commonly referred to as a certificate, is a digitally signed statement that links the value of a public key to the identity of the person, device, or service that holds the corresponding private key. One of the primary advantages of certificates is that they eliminate the need for passwords for individual clients requiring authentication before access. Instead, trust is established through the certificate issuer.

 In the certificates, you will find the following information:

  • The subject’s public key value.
  • The subject’s identifier information, such as the name and e-mail address.
  • The validity period (the length of time that the certificate is considered valid).
  • Issuer identifier information.
  • The digital signature of the issuer. A certificate is valid only for the period specified within it; every certificate contains valid from and valid to date, which set the boundaries of the validity period.

Certificate Authority (CA)

A Certificate Authority (CA) is an organization that issues certificates to entities seeking to verify their identity. The CA requires the certificate requester to provide information about itself and, in return, issues a certificate. This certificate is linked to the root certificate, creating a chain of trust. As a result, anyone interacting with a company that identifies itself using a certificate issued by a specific CA does not need to trust every company individually; trusting the root CA is sufficient.

Java (J2SE) recognizes common root certificates, such as those issued by Verisign and Thawte, which are stored in the JRE’s lib/security/cacerts truststore. However, in some cases, a certificate may not be recognized and must be manually imported into the Java truststore.

HTTPGETCLOBVERBOSE

The HTTPGETBLOBVERBOSE and HTTPGETCLOBVERBOSE REST table functions to retrieve a binary or text-based resource from a specified URL using an HTTP GET request. They return a single-row table containing the standard HTTP response for the request, along with the header information from the HTTP response.

The schema is SYSTOOLS.

URL

Specifies the URL at which to complete the request. This argument is defined as a VARCHAR(2048) CCSID 1208 value.

httpHeader

Specifies an optional header XML document. To use the default HTTP header, specify NULL or the empty string. This parameter is a CLOB(10K) CCSID 1208 or an XML value.

 SQL:

Select * from table(systools.httpgetclobverbose(‘https://yo95w2x80l.execute-api.us-east-2.amazonaws.com/live/holidays’,

                    ‘<httpHeader><header name=”Content-Type” value=”application/json”></header></httpHeader>’

                    ));

HTTP_GET_VERBOSE

HTTP functions are used to make HTTP requests for accessing web services. These functions enable SQL programmers to utilize Representational State Transfer (RESTful) principles through SQL, including Embedded SQL. They offer the same capabilities as the SYSTOOLS HTTP functions but without the overhead of creating a JVM. These functions leverage the HTTP Transport APIs, which are part of the Integrated Web Services (IWS) client for ILE support.

To use the HTTP functions, 5770SS1 Option 3 (Extended Base Directory Support) and 5770SS1 Option 34 (Digital Certificate Manager) must be installed on the system.

The HTTP services are implemented through the QSYS/QSQAXISC service program. A system administrator can disable access to the HTTP services by modifying the authority on the QSYS/QSQAXISC service program. The authority assigned to the QSYS/QSQAXISC service program applies to all HTTP functions.

These HTTP functions accept parameters that specify the HTTP server to access, the configuration of the HTTP headers, and any data to be sent to the server. The parameters are consistent across all HTTP functions.

  • The first parameter is the URL of the server.
  • The second parameter is a string that indicates the options to be used on the request. These options include the setting of the HTTP headers. The string is a JSON object with the following format:
    {“option”:”option-setting”,”option”:”option-setting”}

SQL:

Select * from table(HTTP_GET_VERBOSE(

   URL => ‘https://yo95w2x80l.execute-api.us-east-2.amazonaws.com/live/holidays‘,

   OPTIONS => ‘{“header”:”content-type,application/json”,

                “sslCertificateStoreFile”:”/home/javaTrustStore/fromJava.KDB”}’

                        ));

Comparison

A simple side-by-side comparison highlights three items (see Figure below):

  • Note the similarity in the SQL statement text. To shift to the new QSYS2 functions might be as simple as changing “SYSTOOLS.HTTPGETCLOB” to “QSYS2.HTTP_GET”.
  • Note the difference in query execution time.
  • Note the difference in thread count after the query execution. The additional threads in the SYSTOOLS example are related to the use of Java.
systool-one
systool

Conclusion

Consuming HTTPS REST APIs on an AS/400 opens possibilities for integration with modern systems. By configuring SSL, writing RPGLE code, and parsing JSON responses, you can seamlessly bridge the gap between legacy applications and contemporary web services.

Stay tuned for more advanced examples and techniques to leverage APIs on your IBM i

system.

SHARE: