/apidevelopment/index.htmlAPI Development This chapter describes the procedure ow writing new APIs. How to describe API in OpenApi specification. Here You can also find information about tools which we recomend to use by developers.Hugoen-usFri, 04 Nov 2022 09:50:59 +0100/apidevelopment/prerequisits/index.htmlFri, 04 Nov 2022 09:50:59 +0100/apidevelopment/prerequisits/index.htmlPrerequisites The API development and testing process require the use of third-party tools. Git Git is a tool used for source code managenent. It is a free and open source version control system used to handle various projects in Iptor. All API-related objects are stored in repositories on the server https://gitlab.int.iptor.com/, and for their effective use it is necessary to install GIT locally./apidevelopment/deployment/index.htmlThu, 03 Nov 2022 09:18:18 +0100/apidevelopment/deployment/index.htmlThis chapter describes how API Bridge and connected elements are deployed in internal and cloud infrastructure. Note: The elements described here are described only from PD perspective. Meaning, the deployment for internal use. There are several elements in API landscape which needs to be run and they are connected with each other. Element Development GitLab Deployment GitLab Aperio Backend N/A. RPG based located on IBMi N/A. Manually deployed on IBMi API Bridge development project GitLab deployment GitLab API Documentation development project GitLab deployment GitLab Mock server development project GitLab deployment GitLab All above projects (except Aperio Backend) have corresponding projects in GitLab repositories. There is general rule to keep at least two branches for each repository:/apidevelopment/explain_openapi_driven/index.htmlThu, 03 Nov 2022 09:16:42 +0100/apidevelopment/explain_openapi_driven/index.htmlAPI Bridge is OpenAPI driven. What does it mean? It means API bridge exposes ONLY rest API endpoints that are described in its OpenAPI specification which was provided when API Bridge was started. There are two groups of endpoints exposed by API bridge. Static API Endpoints There are several core API endpoints exposed from API bridge. Like admin, rpc, health endpoints. Detailed description of all static (core) endpoints you can find here./apidevelopment/openapi_naming/index.htmlThu, 03 Nov 2022 13:56:31 +0100/apidevelopment/openapi_naming/index.htmlThis document describes naming rules for OpenAPI files. All OpenAPI specifications must be kept in GitLab folder structure. We have three main scenarios: 1. Standard API written in core systems They are stored in the git project in “openapi/base” folder. Mainly we keep one OpenAPI file per all standard APIs. There is exception is CRM. API specification for CRM is kept separately as we want to have it described but we do not plan to expose it to the customers./apidevelopment/xaperio/index.htmlThu, 03 Nov 2022 13:18:34 +0100/apidevelopment/xaperio/index.htmlIn OpenApi we have special places where Aperio specific elements can be defined. These sections are defined as “x-aperio”. Mainly there are two sections where “x-aperio” may exist. x-aperio on http method level “x-aperio” on http method level is to define which program must be bun on IBM i whenever someone calls this API http method./apidevelopment/openapi_work_procedure/index.htmlThu, 03 Nov 2022 13:50:21 +0100/apidevelopment/openapi_work_procedure/index.htmlThis article describes how a daily routine looks like for developer in case of OpenAPI file. OpenAPI file is simply a descriptioon of API. It describes: the path and all parameters needed to call API behavior of API possible HTTP response codes response data structures etc… Every time you write a new API or adjust existing one you need to update OpenAPI specification. More information about OpenAPI standard you can find here. The OpenAPI specification for all APIs delivered in DC1 standard is kept in GitLab. Note, that all API specifications for standard DC1 are kept in one JSON file. The files are stored in two branches:/apidevelopment/design_first/index.htmlThu, 03 Nov 2022 09:21:56 +0100/apidevelopment/design_first/index.html“Design first” process It can be divided into 3 parts: API ideation OpenApi specification Coding API ideation Verbal description of API that we want to have and what we want to achieve by it, including resource (usually abstract object) definition to which our API is referring to and data that are going to be provided and handled by API. As a final result of this part we should provide information about:/apidevelopment/dc1_naming/index.htmlTue, 14 Jul 2020 15:01:31 +0200/apidevelopment/dc1_naming/index.htmlThis section describes recommended naming rules for all objects and names connected to API programing in DC1. DC1 Back end naming standard Name of object is related to its functionality. All programs implementing the functions of the existing applications and called from manager programs should have names in accordance with back end naming convention (for DC1 e.g. DI*, DM*, DS*… for DIS, GDM* for GEN….). Unlike the standard applications, program manager names and related files should start with three-character prefix MGR. For customer modifications the name of program should start with Z* (example: Z1MGRR001)/apidevelopment/token/index.htmlThu, 03 Nov 2022 13:25:17 +0100/apidevelopment/token/index.htmlJWT tokens are used to secure API calls. There are two typs of tokens we use in API Bridge. API Bridge internal JWT token (legacy) API Bridge internal tokens are used to secure /rpc endpoints. Communication through these endpoints is used oly internally between: ERP UI and API Bridge Iptor CRM and API Bridge Iptor CRM Notification engine and API Bridge P27 done using NiFi and API Bridge Aperio Client (mobile apps) and API Bridge New sales order entry and API Bridge To obtain token from API Bridge, client application muust first call POST /rpc/login and provide as payload: user, password, DC1 company code. User and password are for IBM i. As response, API Bridge issues token and refreshToken. These two tokens must be saved in client application storage. Then every future API call must be accompanied with token in the authorization HTTP header./apidevelopment/postman/index.htmlThu, 03 Nov 2022 13:24:06 +0100/apidevelopment/postman/index.htmlPostman is a platform to build, test, design, modify, and document APIs. It simplifies each step of the API lifecycle. You can run tests from design level (with mock server) to implementation. Install Postman https://www.postman.com/downloads/ Documentation to start : https://learning.postman.com/docs/getting-started/introduction/ How to start You can import existing collection (most often as json file). You can create a new collection. If you start with a new API you can import OpenAPI specification. The collection will be divided into folders according to the endpoints hierarchy. Postman uses the schemas defined in the OpenAPI to generate request and response bodies./apidevelopment/api_client_tutorial/index.htmlFri, 04 Nov 2022 09:46:27 +0100/apidevelopment/api_client_tutorial/index.htmlto describe how to build API client… with keycloak authentication etc…./apidevelopment/performance/index.htmlFri, 04 Nov 2022 09:49:11 +0100/apidevelopment/performance/index.htmlTo odescribe: requrements performance tuning