API landscape overview :: Aperio Documentation

Two development streams for API

Wed, 16 Dec 2020 14:00:00 +0200

API platform consists of many elements: Aperio Backend (Set of objects needed to write API in RPG on IBM i and expose those RPG programs as API) API Bridge (Communication middleware to access RPG programa as REST services) Aperio Client (Server which serves Mobile applications) API Tool (Simple application which helps developers to write APIs) Mobile Apps (Set of html/js and config files which acts as mobile application) API documentation server (Server which shares official documentation of all Iptor APIs) API Mock server (Server which emulates the backend API server. It can be used to produce fake answers for API. Usually used to help develpers to understand how API reponse looks like) Keycloak (Open source software used as a central server to authenticate and authorize API requests) Above elements are developed/configured by Iptor. Some of them are developed in two versions. One to use by On-prem customers and the second to use in Iptor cloud. Depending on how these elements will be used (in cloud or on prem) they can have different names or they can have differences in functionality.

Aperio Backend

Wed, 16 Dec 2020 14:00:00 +0200

To allow programmers to write RPG programs which will act as API we had to create Aperio Backend layer. This is a simple new library (IAF100AP) which should be included in RPG projects. This new library plays two roles in the API landscape: Delivers RPG tools for RPG developers needed to easly write RPG programs which will act as APIs. It contains communication mechanisms which allows RPG programs to communicate with API Bridge in standardized way. The typical installation of Aperio Backend (IAF100AP) is to just put it on IBM i and set up the system so that this new library is available during compilation and runtime of RPG programs . Library IAF100AP must be on the library list.

API Bridge

Wed, 16 Dec 2020 14:00:00 +0200

API Bridge is container solution which joins IBM i with HTTP world. It is used to convert HTTP requests into Iptor internal IADF (Iptor API Data Format), then it calls RPG program. The response generated by RPG program is converted back to HTTP response. API Bridge allows to publish RPG backend programs as REST services. API Bridge plays several roles in the API landscape: HTTP <-> IADF (Iptor API Data Format) interpreter Authorizes HTTP requests by checking incoming requests with external authentication provider (currenty Keycloak) Session handling with job pooling. Creates and configures IBM i sessions. Exposes REST Web Services based on OpenAPI specification. Regardless how many RPG programs exist on IBM i backend, API Bridges exposes only these which are included in OpenAPI specification. See OpenAPI driven API Additionally, has a built-in mechanism to read RPG program and generate OpenAPI specification for it. Endpoints Below is the list of endpoints that are exposed by API Bridge (only summary information provided). For more information, see Core OpenApi specification.

API documentation server

Thu, 03 Nov 2022 13:21:22 +0100

One element of API Platfom landscape is API documentation server. This server shares information about available API exposed by Iptor. API Documentation server is built based on Swagger UI server, and is used to expose OpenAPI sepcifications. It plays two roles in API platform infrastructure: Publishing documentation about Iptor APIs in human readeable form. Sharing OpenAPI specification within our network infrastructure. The first point is quite obvious, but second need some explanation. To expose API in Iptor infrastructure we use API Bridge software. API Bridge software exposes “core API endpoints” which are hardcoded in this program. It also exposes dynamic API endpoints. These dynamic API endpoints are based on OpenAPI specification injected during start of API Bridge container. To inject OpenAPI specification we use shared document from API documentation server. We use also API documentation server to serve OpenAPI spec as source for API Gateway configuration.

API mock server

Thu, 03 Nov 2022 13:21:12 +0100

General info API Mock Server is the server which simulates responses for API requests. It is driven by OpenAPI specification. Using OpenAPI specification the server may prepare fake answers for API requests. Usually mock servers are used by developers to try out APIs and understand better what they can expect from API responses. Developers can create their application without presence of real backend server. They just dirrect API calls to mock server and can build and test their application with fake data. At PD we use two solutions for mock servers:

Keycloak

Thu, 03 Nov 2022 17:11:30 +0100

There are three reasons why we need Keycloak in API landscape: Authorization Keycloak is an open source identity and access management system. It provides OAuth 2.0 standard to authorize our REST API calls. Every call that comes to API Bridge need to have header (Authorization) which contains Keycloak access token. Authorization: "Bearer eyJhbGciO....ertree" So, authorization of API reqeusts is one of the reasons we use Keycloak.

API Gateway

Fri, 04 Nov 2022 09:22:21 +0100

Comming soon.

Aperio Client

Fri, 05 Jun 2020 14:34:02 +0200

Aperio Client is a base web app used to provide simple mobile applications with forms generated from Iptor scripts (JForms). Aperio Client delivers login/logout functionality and common look and feel for all Iptor Mobile applications. There are two types of Aperio Client. See “Two development streams for API”: Aperio Client available for on-prem DC1 customers. In this case Aperio client is a part of XT Dispatcher. Mobile applications are packaged as XT add-ons and delivered separately. They ned to be installed on XT and activated by XT configuration. Aperio Client packaged as image that runs as a container. In this case it is a separate container installed for Cloud customers. All mobile apps are injected into the container automatically. To run a mobile application, you only need to provide the application name in the app URL as query parameter. For example: {aperio client server}/aperio/app?name={app name} Note: Even if initially all applications are injected in Aperio Client container the infrastructure administrator may decide to run Aperio Client where only one application available. It is depends on the customer license.

Versions

Thu, 03 Nov 2022 13:27:29 +0100

This document describes version compatibility betwenn XT and Aperio backend for on-prem installations. Additionaly it shows compatibility for Cloud solution of API Bridge and Aperio backend. Detail infromation about each product versions you can find here. Product Home page link GitLab XT User Interface XT Git API Bridge API Bridge Release notes API Bridge Git Aperio Backend API Download Center N/A XT vs Aperio Backend XT UI Server Compatible Aperio backend versions 4.5.0.4 or higher 2.2.0.2 ,2.2.0.6, 2.2.1.0 4.5.1.6 or higher 3.0.0.0 Cloud API Bridge vs Aperio backend API Bridge version Compatible Aperio backend versions 1.0.1 2.2.1.0 2.0.0 or higher 3.0.0.0