Changes for page API Gateway - Introduction
Last modified by Danniar Firdausy on 2024/09/02 16:51
Summary
-
Page properties (1 modified, 0 added, 0 removed)
Details
- Page properties
-
- Content
-
... ... @@ -46,10 +46,10 @@ 46 46 [[image:Main.Images.Microlearning.WebHome@releasenote-apigw-2.png]] 47 47 48 48 49 - **1. Capture your API Gateway**49 +1. Capture your API Gateway 50 50 In this phase, the regular operations or message types can be captured with all the necessary information of that specific operation. At the system level, you can indicate that the system acts as a backend service provider that has certain API's available 51 51 52 - **2. Design an API Gateway**52 +1. Design an API Gateway 53 53 This is the central phase in the configuration of the API Gateway. The main idea is that the entire Gateway should be configured from the Design phase The front-end Gateway is the part where the external application user(s) can access the specific operation published and where the application user is authorized for. Specific operations can be configured and documented including parameters and response types. In the backend operation provider (an eMagiz system), the actual link to the backend operations can be registered including parameters. Frontend and backend operations can be connected at the moment an operation is exposed in the eMagiz API Gateway. Integrations or message types connected to a backend operation providing system are now able to have operations as child objects to get a better overview of what operations are available. Operations are still the integrations reported in the various parts of eMagiz * the message type becomes more of a group object. 54 54 55 55 * In case the backend service provider has an OpenAPI 3.0 specification available, this can be imported to have everything directly configured. Documentation of what OpenAPI statements are supported can be found in the help texts.