A low-code-based API transparent transmission method

The API transparent transmission method designed through the low-code mode solves the complexity and professionalism problems of API gateway agents in the existing technology, realizes the unified management and secure integration of APIs, and improves the flexibility and integration efficiency of the system.

CN120186226BActive Publication Date: 2025-10-03HAND ENTERPRISE SOLUTIONS CO LTD
View PDF 2 Cites 0 Cited by

Patent Information

Application Number
CN202510148840.0
Authority / Receiving Office
CN · China
Patent Type
Patents(China)
Current Assignee / Owner
Filing Date
2025-02-11
Publication Date
2025-10-03
Estimated Expiration
2045-02-11

AI Technical Summary

Technical Problem

The existing API gateway proxy implementation requires professional technical personnel to maintain, is complex to expand, lacks interface configuration, and cannot achieve unified management and security of APIs.

Method used

The API transparent transmission method designed with a low-code model uniformly registers and publishes APIs through a proxy system, supports multi-protocol integration and protocol conversion, provides interface configuration and data processing, and realizes transparent transmission and unified management of APIs.

Benefits of technology

It achieves flexible, unified and secure API integration, simplifies the operation and maintenance process, reduces dependence on professional technicians, and improves integration efficiency and system flexibility.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN120186226B_ABST
    Figure CN120186226B_ABST
Patent Text Reader

Abstract

The present invention relates to the field of computer technology, and specifically to a low-code-based API transparent transmission method. The method comprises the following steps: S1, registering the target API to the proxy system and configuring the API enhancement function as required; S2, publishing the registered API in a unified manner and exposing the proxy address to the outside world; S3, receiving the proxy API request information from the client, and parsing the target API type and parameters; S4, obtaining the target API information from the API configuration database according to the parsed target API type; S5, processing the data in the request to meet the requirements of the target API; S6, sending the processed data to the target API; S7, receiving the result data returned by the target API, and processing the result data to meet the requirements of the client. Compared with the existing technology, the low-code mode is used to accelerate enterprise system integration, enhance the flexibility, unity and security of the enterprise integration system, and achieve the purpose of API multi-protocol integration, protocol conversion, and API capability reuse.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] The present invention relates to the field of computer technology, and in particular to a low-code-based API transparent transmission method. Background Art

[0002] With the development of information technology, more and more companies are adopting APIs provided by various third-party services to enrich their product functionality. However, directly using these APIs presents many inconveniences, including inconsistent API addresses, authentication protocols, and security issues, as well as insufficient operational and maintenance capabilities.

[0003] Traditional API gateway proxy implementations typically leverage port forwarding, pre-configuring forwarding rules for different ports on the proxy device. Requests between the caller and the target provider then interact on these configured ports. This implementation has two drawbacks: First, ports must correspond to the services on both sides. Proxy devices are opaque, requiring a one-to-one mapping between ports and services, making operations and maintenance inconvenient and complicating subsequent expansion. Second, port forwarding rules must be configured in advance. Currently, most proxy devices lack a user-friendly interface, making rule maintenance difficult and requiring specialized technical personnel. Summary of the Invention

[0004] In order to overcome the shortcomings of the existing technology, the present invention provides a low-code-based API transparent transmission method, aiming to accelerate enterprise system integration in a low-code mode, enhance the flexibility, unity and security of the enterprise integration system, and achieve API multi-protocol integration, protocol conversion, and API capability reuse.

[0005] To achieve the above objectives, a low-code-based API transparent transmission method is designed, which includes the following steps:

[0006] S1, register the target API to the proxy system and configure API enhancement functions as required;

[0007] S2, the proxy system publishes the registered APIs in a unified manner and exposes the proxy address to the outside world;

[0008] S3, receives the proxy API request information from the client through the proxy system and parses the target API type and parameters;

[0009] S4, the proxy system obtains the target API information from the API configuration database according to the parsed target API type;

[0010] S5, processes the data in the request through the built-in components of the proxy system to meet the requirements of the target API;

[0011] S6, sends the processed data to the target API through the selected transmission channel through the built-in components of the proxy system;

[0012] S7, the built-in component of the proxy system receives the result data returned by the target API and processes the result data to meet the client's requirements.

[0013] The proxy system includes a RESTful direct transparent transmission component, a non-SOAP to RESTful transparent transmission component, a SOAP direct transparent transmission component, a RESTful to SOAP component, and a SOAP to RESTful component.

[0014] In step S1, the target API type supports internal APIs within the proxy system, external APIs outside the proxy system, data source SQL, and file reading via (S)FTP; external APIs outside the proxy system include REST, SOAP, and GRPC.

[0015] In the step S2, the proxy system has a unified proxy gateway address, and the proxy system generates a proxy address with a unique identifier according to the relevant information when registering the API according to the rules.

[0016] In step S3, the proxy system obtains the unique identifier in the client's request API and reversely parses the relevant information of the registration API through rules.

[0017] In step S4, all information of the registration API is obtained from the preset cache database based on the de-parsed registration API related information, including API enhancement function configuration information and target API information; wherein the API enhancement function configuration information includes API authentication, field conversion, data conversion, data encryption, retry configuration, and log alarm; the target API information includes the request address, request method, and request protocol of the target API.

[0018] In the step S5, the request data is processed according to the acquired API enhancement function configuration information by the built-in component of the proxy system.

[0019] In step S6, the target API information is obtained through the built-in component of the proxy system, and the data processed by the proxy component is sent to the target API. The data transmission channel includes HTTP, HTTPS, and RPC.

[0020] In the step S7, the response data of the target API is processed using the API enhancement function configuration information obtained by the built-in component of the proxy system.

[0021] The process also includes step S8, wherein the proxy system records the call status and issues necessary alarms.

[0022] Compared with the prior art, the present invention has the following beneficial effects:

[0023] 1. Unified registration and management of multiple types of APIs, unified release of transparent transmission addresses and transparent transmission request support;

[0024] 2. Interface configuration allows for quick access to standard or personalized APIs, and low-code configuration for enhanced API processing;

[0025] 3. Support multi-protocol registration, including RESTful, SOAP, GRPC, (S)FTP, SQL, etc.;

[0026] 4. The traditional Webservice coding integration model is extremely simplified through the low-code model. Users do not need to pay attention to the complexity of the SOAP protocol itself and the repetitive workload caused by understanding it. The connection can be achieved through convenient registration.

[0027] 5. Provide API call link logs, API detailed log monitoring, provide rich statistical charts, and support abnormal alarms. BRIEF DESCRIPTION OF THE DRAWINGS

[0028] Figure 1 It is a schematic diagram of the process of the present invention.

[0029] Figure 2 Schematic diagram of the agent system of the present invention. DETAILED DESCRIPTION

[0030] The present invention will be further described below with reference to the accompanying drawings. Example

[0031] like Figure 1 As shown, the low-code-based API transparent transmission method in this embodiment includes the following steps:

[0032] S1, register the target API to the proxy system and configure API enhancement functions as required;

[0033] S2, the proxy system publishes the registered APIs in a unified manner and exposes the proxy address to the outside world;

[0034] S3, receives the proxy API request information from the client through the proxy system and parses the target API type and parameters;

[0035] S4, the proxy system obtains the target API information from the API configuration database according to the parsed target API type;

[0036] S5, processes the data in the request through the built-in components of the proxy system to meet the requirements of the target API;

[0037] S6, sends the processed data to the target API through the selected transmission channel through the built-in components of the proxy system;

[0038] S7, the built-in component of the proxy system receives the result data returned by the target API and processes the result data to meet the client's requirements.

[0039] like Figure 2 As shown, the proxy system includes a RESTful direct transparent transmission component, a non-SOAP to RESTful transparent transmission component, a SOAP direct transparent transmission component, a RESTful to SOAP component, and a SOAP to RESTful component.

[0040] The RESTful direct transparent transmission component supports APIs within the proxy system and RESTful APIs outside the system, maintaining request parameter calls and response message data structures consistent with the target original API, and providing authentic transparent transmission calls.

[0041] The non-SOAP to RESTful transparent transmission component supports the conversion of data source SQL, (S)FTP file reading, and GRPC protocol API to RESTful protocol, maintaining the same request parameter calls as the target API protocol.

[0042] SOAP direct transparent transmission component, the proxy system provides one-click registration of SOAP interface, eliminating the cost of understanding complex WSDL messages, and can be used by people at any time; based on the definition of the source WSDL, a new transparent transmission WSDL message that is almost identical to the source WSDL is generated, and the new transparent transmission WSDL supports parsing and calling by tools such as SOAPUI.

[0043] RESTful to SOAP component, the proxy system provides one-click configuration to convert RESTful to SOAP interface. New WSDL definition message can be generated by configuring parameters. It supports parsing calls by tools such as SOAPUI to obtain complete XML messages.

[0044] The SOAP to RESTful component, the proxy system provides one-click configuration to convert SOAP into RESTful interface, and the request parameters and response messages are fully converted to JSON messages.

[0045] Through the above components, the proxy system encapsulates a transparent API that provides a calling experience that is almost identical to the native API. It can achieve zero-code conversion of RESTful to SOAP interface, SOAP interface to RESTful interface, etc., to achieve transparent API transmission and protocol conversion.

[0046] Through the method of this embodiment, since the registration of the target API, the configuration of API enhancements, and the unified release of APIs are all visually configured on the proxy system interface of this embodiment, and the configuration takes effect immediately after the change, API integration and proxying can be achieved efficiently and in real time. The proxy component can be used to implement API authentication, data processing, data encryption, etc. for the request and response process of the target API, which can meet the flexibility and security requirements of API integration. The proxy component can be used to achieve the integration of many protocols such as HTTP(S), GRPC, (S)FTP, SQL, etc.

[0047] In step S1, the target API type supports internal APIs within the proxy system, external APIs outside the proxy system, SQL data sources, and (S)FTP file access. External APIs outside the proxy system include REST, SOAP, and GRPC. The proxy system provides a corresponding API registration interface based on the target API type. By configuring the interface configuration fields one by one, target API registration and proxy configuration can be quickly and easily completed. For example, the target API's request address, request method, and request protocol are all configured. The proxy system of the present invention provides one-click automated proxy configuration; simply fill in the request address to automatically complete proxy configuration, simplifying maintenance.

[0048] In step S2, the proxy system has a unified proxy gateway address. The proxy system generates a unique proxy address according to the rules based on the relevant information during API registration. For example, http: / / demo.com / invoke / xxx, where xxx represents the unique identifier of the API. This embodiment unifies the proxy address. Unlike other proxy device implementations that require different proxy ports and use port forwarding to achieve proxying, this embodiment does not require port forwarding. Instead, it can find a unique target API based on the API address suffix to achieve API proxy transmission.

[0049] In step S3, the proxy system obtains the unique identifier in the client's API request and reversely parses the relevant information of the registered API through rules.

[0050] In step S4, all registration API information is retrieved from a preset cache database based on the de-parsed registration API-related information, including API enhancement configuration information and target API information. The API enhancement configuration information includes API authentication, field conversion, data conversion, data encryption, retry configuration, and log alerts. The target API information includes the target API's request address, request method, and request protocol. This embodiment completely hides the target API's information. The caller only needs to use the proxy system's proxy address to find the target API. The call and transmission methods are consistent with the original target API, achieving completely transparent transmission.

[0051] In step S5, the request data is processed according to the acquired API enhancement function configuration information through the built-in components of the proxy system. Compared with the traditional proxy device, this embodiment adds a request data processing link. The traditional proxy device generally lacks the processing of request data and needs to be hard-coded for a specific API. Even if it can be configured, the configuration is difficult. The proxy system of this embodiment provides interface visualization and drag-and-drop configuration to realize request data processing, which mainly includes API authentication, field conversion, data conversion, data encryption, etc., which correspond to the corresponding enhancement components respectively and can be used alone or in combination, thereby enhancing the flexibility and variability of the API transmission process.

[0052] In step S6, the target API information is obtained through the built-in components of the proxy system, and the data processed by the proxy component is sent to the target API. The data transmission channels include HTTP, HTTPS, and RPC, and support multi-protocol transmission and protocol conversion. For example, if the target API protocol is SOAP, the caller can use the RESTful protocol to transmit through the proxy system.

[0053] In step S7, the response data of the target API is processed using the API enhancement function configuration information obtained through the built-in components of the proxy system. This embodiment adds a response data processing link compared to traditional proxy devices. Traditional proxy devices generally lack response data processing and need to hard-code specific APIs. Even if they can be configured, the configuration is difficult. The proxy system of this embodiment provides interface visualization and drag-and-drop configuration methods to realize response data processing, which mainly includes field conversion, data conversion, data encryption, etc., which correspond to corresponding enhancement components respectively and can be used alone or in combination, thereby enhancing the flexibility and variability of the API transmission process.

[0054] The system also includes step S8, where the proxy system records the call status and issues necessary alerts. Specifically, the proxy system records the API transmission process, including request parameters, request time, request address, response results, etc.; generates API call statistics, including call status, response time, traffic statistics, and other statistical reports; and issues API call anomaly alerts.

[0055] The present invention supports internal interfaces, external interfaces, GRPC, data source SQL, (S)FTP and other protocol interfaces to be published as interfaces in an interface configuration manner, supports RESTful and SOAP publishing, and realizes completely transparent transmission. The traditional Webservice coding integration mode is extremely simplified through a low-code mode, and low-code configuration is realized to realize protocol conversion. Provide API enhanced configuration functions in the API transmission process, such as API authentication, data conversion, data encryption, log extraction, caching, etc. are all provided in an interface configuration manner. A variety of monitoring solutions are built in, from QPS monitoring for real-time transparent transmission, to monitoring of complex long-link API chain calls, to fault failure alarm notifications and message notifications of daily transparent transmission call reports, to the final display of large-screen statistical analysis reports of transparent transmission calls.

[0056] The present invention achieves a very simplified traditional Webservice coding integration model through a low-code model. Users do not need to worry about the complexity of the SOAP protocol itself and the repetitive workload caused by understanding it. The connection can be achieved through convenient registration. In particular, if the traditional model needs to be converted to the RESTful protocol specification, the complexity, repetitiveness, instability and other factors brought about by the coding will greatly restrict the efficiency of integration. The simplified model of the present invention can be configured with one click, and even the RESTful conversion can be achieved with the same configuration, which brings about very considerable integration efficiency.

Claims

1. A low-code-based API transparent transmission method, characterized by: The steps include: S1, register the target API to the proxy system and configure API enhancement functions as required; S2, the proxy system publishes the registered APIs in a unified manner and exposes the proxy address to the outside world; S3, receives the proxy API request information from the client through the proxy system and parses the target API type and parameters; S4, the proxy system obtains the target API information from the API configuration database according to the parsed target API type; S5, processes the data in the request through the built-in components of the proxy system to meet the requirements of the target API; S6, sends the processed data to the target API through the selected transmission channel through the built-in components of the proxy system; S7, the built-in component of the proxy system receives the result data returned by the target API and processes the result data to meet the client's requirements.

2. The low-code-based API transparent transmission method according to claim 1 is characterized in that: The proxy system includes a RESTful direct transparent transmission component, a non-SOAP to RESTful transparent transmission component, a SOAP direct transparent transmission component, a RESTful to SOAP component, and a SOAP to RESTful component.

3. The low-code-based API transparent transmission method according to claim 1 is characterized in that: In step S1, the target API type supports internal API within the proxy system, external API outside the proxy system, data source SQL, and file reading of (S)FTP; External APIs outside the proxy system include REST, SOAP, and GRPC.

4. The low-code-based API transparent transmission method according to claim 1 is characterized in that: In the step S2, the proxy system has a unified proxy gateway address, and the proxy system generates a proxy address with a unique identifier according to the relevant information when registering the API according to the rules.

5. The low-code-based API transparent transmission method according to claim 1, characterized in that: In step S3, the proxy system obtains the unique identifier in the client's request API and reversely parses the relevant information of the registration API through rules.

6. The low-code-based API transparent transmission method according to claim 1, characterized in that: In the step S4, all information of the registered API is obtained from a preset cache database according to the de-parsed registered API related information, including API enhancement function configuration information and target API information; The API enhancement function configuration information includes API authentication, field conversion, data conversion, data encryption, retry configuration, and log alarms. The target API information includes the request address, request method, and request protocol of the target API.

7. The low-code-based API transparent transmission method according to claim 1, characterized in that: In the step S5, the request data is processed according to the acquired API enhancement function configuration information by the built-in component of the proxy system.

8. The low-code-based API transparent transmission method according to claim 1, characterized in that: In step S6, the target API information is obtained through the built-in component of the proxy system, and the data processed by the proxy component is sent to the target API. The data transmission channel includes HTTP, HTTPS, and RPC.

9. The low-code-based API transparent transmission method according to claim 1, characterized in that: In the step S7, the response data of the target API is processed using the API enhancement function configuration information obtained by the built-in component of the proxy system.

10. The low-code-based API transparent transmission method according to claim 1, characterized in that: The process also includes step S8, wherein the proxy system records the call status and issues necessary alarms.

Citation Information

Patent Citations

  • Dynamic proxy method

    CN113630468A

  • Service integration process abstraction method and device and computer equipment

    CN114153626A