An API calling method, system, device and medium based on a meta model
By using a meta-model-based API calling method, zero-code adaptation for cross-system integration is achieved, solving the problem of interface differentiation requirements in cross-system integration, reducing costs and improving efficiency.
Patent Information
- Application Number
- CN202410724662.7
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- Filing Date
- 2024-06-05
- Publication Date
- 2025-11-04
- Estimated Expiration
- 2044-06-05
AI Technical Summary
Existing technologies struggle to quickly respond to the diverse interface requirements of different manufacturers when integrating across systems, resulting in high costs and low efficiency.
The API calling method based on meta-model is adopted. External requests are obtained through a unified API interface, internal protocol conversion and logical parameter mapping are performed, and output parameter templates are dynamically configured to achieve zero-code adaptation and meet the request and return format requirements of different systems.
It enables configurable development, reduces interface integration costs, improves response speed and adaptability, and meets the differentiated interface requirements of different systems.
Smart Images

Figure CN118733104B_ABST
Abstract
Description
TECHNICAL FIELD
[0001] The present application relates to the technical field of meta-model, and particularly relates to an API calling method and system based on a meta-model, a device and a medium. BACKGROUND
[0002] With the rapid development of global informatization, the vision of system users has also shifted from vertical system function construction to horizontal system connection, that is, integration between systems. At present, the cost of providing services to meet changing needs is very high. At present, a new service and a new return format can be provided by code when integration is needed through hard coding. However, the efficiency of this method is very low. Different codes need to be written to achieve different requirements, and it is difficult to quickly respond to the differentiated needs of different manufacturers. SUMMARY
[0003] The present application provides an API calling method, system, device and medium based on a meta-model to solve the problems in related technologies. The technical solution is as follows:
[0004] In a first aspect, the present application provides an API calling method based on a meta-model, comprising:
[0005] An API interface based on a meta-model obtains an external request, converts an internal protocol for the external request, and obtains internal logic parameters;
[0006] The internal logic parameters are mapped to a specified model and a corresponding service is executed to obtain return parameters;
[0007] The return parameters are converted into a return protocol based on a pre-configured parameter template, a return value in a specified format is obtained, and the return value is returned through the API interface.
[0008] In an embodiment, the API interface based on the meta-model obtains the external request, comprising:
[0009] According to a preset routing strategy, the external request obtained from the request address of the API interface is intercepted;
[0010] The intercepted external request is distributed to a request protocol conversion layer for internal protocol conversion.
[0011] In an embodiment, it further comprises:
[0012] A custom configuration parameter of a function configuration interface is obtained;
[0013] The protocol conversion layer is configured for mapping between API routing and meta-model services and parameter template configuration according to the custom configuration parameter.
[0014] In an implementation, the custom configuration parameter includes a request address, an application name, a model name, a service name, and a template code.
[0015] In an implementation, the internal protocol conversion for the external request includes:
[0016] The external request is converted into internal logic parameters based on the input parameter template, the internal logic parameters including an application, a model, and a service.
[0017] In an implementation, the input parameter template configuration includes:
[0018] The template code in a specified format entered through a function configuration interface is obtained, and a placeholder in the template code is identified;
[0019] The template code outside the placeholder is removed to obtain a target code;
[0020] The input parameter template is generated according to the target code.
[0021] In an implementation, the method further includes:
[0022] The protocol template for successful return and the protocol template for error return are defined through the function configuration interface, and corresponding normal output parameter templates and abnormal output parameter templates are generated.
[0023] In a second aspect, an embodiment of the present application provides an API calling system based on a meta model, which executes the API calling method based on the meta model.
[0024] In a third aspect, an embodiment of the present application provides an electronic device, which includes a memory and a processor. The memory and the processor communicate with each other through an internal connection path. The memory is configured to store instructions, and the processor is configured to execute the instructions stored in the memory. When the processor executes the instructions stored in the memory, the processor executes the method in any one of the embodiments of the aspects.
[0025] In a fourth aspect, an embodiment of the present application provides a computer readable storage medium, which stores a computer program. When the computer program is executed on a computer, the method in any one of the aspects is executed.
[0026] The advantages or beneficial effects of the above technical solutions at least include:
[0027] The application obtains external requests based on a unified API interface of a meta-model driven architecture, converts the external requests into internal logic parameters through dynamic configuration functions, and then calls and executes required meta-model services, realizes configuration and zero-code adaptation of external interface calling requirements, and returns according to an out-parameter template format when responding, meets the differentiated requirements of different systems for different request addresses, request formats, return formats and exception processing formats of the same interface, and achieves cost reduction and efficiency increase of interface opening scene development.
[0028] The above summary is merely intended to illustrate the present description and is not intended to limit in any way. Further aspects, embodiments and features of the present application will be readily apparent from the detailed description that follows, taken in conjunction with the accompanying drawings and the following detailed description. BRIEF DESCRIPTION OF DRAWINGS
[0029] In the drawings, like numerals refer to like elements throughout the various drawings. The drawings are not necessarily to scale, the emphasis instead being placed on the relations between various elements. It should be understood that the drawings only depict some embodiments in accordance with the present disclosure and should not be considered limiting of the scope of the present application.
[0030] Figure 1 A flowchart of the API calling method of the present application;
[0031] Figure 2 A function configuration page of the present application;
[0032] Figure 3 A parameter configuration diagram of the present application for realizing the pushing of test results from LIMS to DIM through the function configuration page;
[0033] Figure 4 A schematic diagram of the present application for configuring an out-parameter template through a function configuration page;
[0034] Figure 5 A structural block diagram of an electronic device according to an embodiment of the present application. DETAILED DESCRIPTION
[0035] In the following, only some exemplary embodiments are described briefly. As those skilled in the art can recognize, the described embodiments can be modified in various different ways without departing from the spirit or scope of the present application. Therefore, the drawings and the description are considered to be essentially exemplary rather than limiting.
[0036] Embodiment one
[0037] With the rapid development of global informatization level, the sight of system users is more from vertical system function construction to horizontal system pull-through, that is, integration between systems; the cost of providing services to meet the changing needs is very high, such as the requirements of other N systems for the HR service of obtaining employee information are different, and there are currently two main methods to achieve: the first is hard coding, which provides new services and new return formats through code when integration is required, and the other is to develop an integration platform (such as enterprise service bus), and all system services are registered to the integration platform for service forwarding, but the above two methods are more reflected in routing forwarding and service arrangement, and do not provide configurable processing for different request formats, return formats, and exception handling formats required by different manufacturers. Therefore, the cost of integration is high, and it cannot quickly respond to customer integration needs.
[0038] To solve the above problems, the embodiment provides an API calling method based on a meta model, realizes configuration and zero-code development, meets the differentiated needs of different systems for different request addresses, request formats, return formats, and exception handling formats of the same interface, and achieves cost reduction and efficiency increase in interface opening scene development.
[0039] The API calling method of the embodiment is implemented based on a meta model architecture, wherein the meta model defines the methods and languages of a specific type of model and describes the elements constituting the model and the relationship between the elements. Figure 1 As shown in the figure, the API calling method specifically includes the following steps:
[0040] Step S1: An API interface based on a meta model is used to obtain an external request, the external request is converted into an internal protocol, and internal logic parameters are obtained;
[0041] Step S2: A specified model is called based on the internal logic parameters, and a corresponding service is executed to obtain return parameters;
[0042] Step S3: The return parameters are converted into a return protocol based on a preconfigured parameter template, a return value in a specified format is obtained, and the return value is returned through the API interface.
[0043] The meta model architecture will provide a unified API interface, and the entrance of all models is the unified API interface. After the API interface receives different requests, different logics are executed according to the differences in request parameters, and different meta model services are executed.
[0044] In the traditional architecture, the original routing information is one-to-one mapped with the internal logic, the external request is directly executed according to the internal logic and returned. In order to realize protocol conversion, the embodiment dynamically maintains the request address of the API interface through the function configuration interface, and generates the corresponding routing strategy, injects the routing strategy into the filter chain, and the filter chain can intercept the external request obtained from the request address of the API interface according to the routing strategy, and distribute the intercepted external request to the request protocol conversion layer for internal protocol conversion. The specific routing strategy can be set according to the actual situation. The request address can be a url address.
[0045] The protocol conversion layer of the embodiment can realize request protocol conversion and return protocol conversion. In the traditional architecture, the parameters carried by the external request are directly matched with the parameters of the internal logic, and when the types do not match or the number does not match, the service is unavailable. The embodiment increases the protocol conversion layer, the external parameters can be defined arbitrarily, the platform establishes the mapping relationship with the internal service parameters, decouples the external request and the internal implementation, and shields the internal implementation logic.
[0046] Before performing protocol conversion, the embodiment needs to configure the mapping relationship between API routing and meta-model service and configure the API input parameter template in the function configuration interface. The mapping between API routing and meta-model service is set in the function configuration interface, and the system generates the function configuration interface according to the preset IU interface code, as shown in Figure 2 The function configuration interface displays "app name", "app version", "model name", "service name", "internal protocol conversion template" and the like, and the user can fill in the corresponding custom configuration parameters in the function configuration interface according to the actual demand, the custom configuration parameters include request address, application name, model name, service name and template code, and the system can determine the input parameter template, protocol conversion rule and the like according to the custom configuration parameters entered in the function configuration interface, so as to transmit the external request proposed by the front end to the back end after protocol conversion, and execute the corresponding model and the corresponding service according to the mapping relationship between the external request and the platform internal APP, model and service, to obtain the return parameter.
[0047] Suppose that the routing is added: / mes / getMeteral, and the mapping with the meta-model unified service is as follows:
[0048] Serial number Parameter Type Configuration value Mandatory Description 1 app String Mes √ app name 2 tag String v1.1 √ app version 3 model String Meteral √ model name 4 service String getMeteral √ service name 5 version String V2 X service version
[0049] The input parameter template can directly generate a default value for a non-mandatory parameter in the protocol conversion process, thereby improving the efficiency of internal protocol conversion. The custom configuration of the input parameter template can define the template according to the parameter format of the unified API, that is, obtain the template code in a specified format entered through the function configuration interface. The code format of the internal protocol conversion template in this embodiment can be a json format. The placeholder in the template code in the specified format is identified, the code outside the placeholder is removed to obtain target code, the input parameter template is generated according to the target code, and the target code is as follows:
[0050]
[0051]
[0052] After the user performs a series of configurations in the function configuration interface, the internal request protocol is encapsulated according to the custom configuration parameters, the specified parameters of the external request are converted to generate default values based on the input parameter template, and the external request is quickly converted into an internal protocol and transmitted to the backend. The backend determines the mapping relationship between the external request and the internal logic parameters according to the custom configuration parameters obtained through the function configuration interface, so as to call the corresponding application, model and service according to the internal logic parameters to perform corresponding operations.
[0053] As shown in Figure 3 , it is assumed that the external request obtained through the request address is that LIMS pushes the test result to DIM. The user inputs the app name as “dim-qms”, the model name as “LIMSToDIM”, and the service name as “limsReturnResult” in the function configuration interface. At this time, the system will determine the mapping relationship between the external request and the application, model and service according to the above configuration content, so as to execute the “limsReturnResult” service to obtain the return parameter of the LIMS pushing the test result to DIM.
[0054] The embodiment can also configure the return protocol conversion while customizing the request protocol conversion, as shown in Figure 4 , the protocol template for successful return and the protocol template for error return are defined through the function configuration interface to generate the corresponding normal output parameter template and abnormal output parameter template.
[0055] The return format based on the meta-model architecture is fixed. The normal format includes List <map>Or Map, abnormal format is Map and main information is put into the object with key error.
[0056] (1) The API out parameter is configured to participate in unified API out parameter mapping, and the API normal out parameter template is configured; the key value in the Map is mainly mapped and configured, and if the key is consistent, no configuration is needed. The key returned by the platform API is mainly data, and the data inside can be a (k, v) pair or a list of (k, v) pairs. The template uniformly uses {} placeholder: for example,
[0057]
[0058]
[0059] (2) The API out parameter is configured to participate in unified API exception out parameter mapping, and the API exception out parameter template is configured; the key value in the Map is mainly mapped and configured, and if the key is consistent, no configuration is needed. The template of the abnormal return format is constructed as follows:
[0060]
[0061] The embodiment will be combined with the meta-model driven architecture, utilize the characteristics of the architecture of unified API, unified input parameter and return format, dynamically increase the api through the routing management function, dynamically establish the request message template, the mapping of the unified entrance of the meta-model architecture, dynamically establish the return message template, the exception message template and the mapping of the unified return format of the meta-model architecture, decouple the actual api and the api format provided, instead of the traditional whole process of writing code, compiling, packaging and publishing when increasing an api. Thus, the configuration, zero code development is realized, the different request addresses, request formats, return formats and exception processing formats of different systems for the same interface are met, and the cost reduction and efficiency increase of the interface opening scene development are achieved.
[0062] Embodiment two
[0063] The embodiment provides an API calling system based on a meta-model, which executes the API calling method based on the meta-model as in the embodiment one. The system comprises:
[0064] The configuration UI interface module is configured to provide and display a function configuration interface, and the function configuration interface can input custom configuration parameters, and determine the internal protocol conversion mode according to the custom configuration parameters;
[0065] The internal protocol conversion module is configured to obtain an external request through an API interface of the meta-model, convert the internal protocol of the external request, obtain internal logic parameters, call a specified model based on the internal logic parameters and execute a corresponding service, and obtain return parameters;
[0066] The return protocol conversion module is configured to perform return protocol conversion on the return parameter according to a preconfigured out-parameter template, to obtain a return value in a specified format, and to return the return value via the API interface.
[0067] The purpose of the embodiment is to realize configuration and zero-code adaptation of external interface calling requirements by dynamically configuring functions based on a unified API of a meta-model driven architecture, to realize automatic routing to the unified API when requesting the API and dynamic return according to the out-parameter template format when responding, and to reduce costs and increase benefits in providing interfaces to the outside.
[0068] The functions of the modules in the system of the embodiment can be referred to the corresponding description in the above method, and will not be repeated here.
[0069] Embodiment Three
[0070] Figure 5 A structural block diagram of an electronic device according to an embodiment of the present application is shown. As shown in the figure, the electronic device includes a memory 100 and a processor 200, and the memory 100 stores a computer program that can run on the processor 200. The processor 200 implements the meta-model-based API calling method in the above embodiment when executing the computer program. The number of the memory 100 and the processor 200 can be one or more. Figure 5
[0071] The electronic device further includes:
[0072] A communication interface 300 for communicating with external devices and performing data interaction transmission.
[0073] If the memory 100, the processor 200 and the communication interface 300 are independently implemented, the memory 100, the processor 200 and the communication interface 300 can be connected to each other through a bus and complete communication therebetween. The bus can be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus, etc. The bus can be divided into an address bus, a data bus, a control bus, etc. For ease of representation, Figure 5 Only one thick line is used in the figure, but it does not mean that there is only one bus or one type of bus.
[0074] Optionally, in a specific implementation, if the memory 100, the processor 200 and the communication interface 300 are integrated on a chip, the memory 100, the processor 200 and the communication interface 300 can complete the communication among each other through an internal interface.
[0075] The computer readable storage medium stores a computer program, and the program is executed by the processor to implement the method provided in the embodiments of the application.
[0076] The chip comprises a processor, which is configured to call and run instructions stored in a memory, so that a communication device installed with the chip executes the method provided in the embodiments of the application.
[0077] The chip comprises an input interface, an output interface, a processor and a memory, the input interface, the output interface, the processor and the memory are connected through an internal connection path, and the processor is configured to execute code in the memory, and when the code is executed, the processor is configured to execute the method provided in the embodiments of the application.
[0078] It should be understood that the processor can be a central processing unit (CPU), and can also be other general-purpose processors, digital signal processors (DSP), application specific integrated circuits (ASIC), field programmable gate arrays (FPGA) or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor can be a microprocessor or any conventional processor, etc. It should be noted that the processor can be a processor supporting an advanced RISC machine (ARM) architecture.
[0079] Further, the aforementioned memory can include a read-only memory, and a random access memory, and can further include a non-volatile random access memory. The memory can be a volatile memory or a non-volatile memory, or can include both volatile and non-volatile memory. The non-volatile memory can include a read-only memory (ROM), a programmable ROM (PROM), an erasable PROM (EPROM), an electrically EPROM (EEPROM), or a flash memory. The volatile memory can include a random access memory (RAM) that is used as an external cache. By way of example, but not limitation, a number of forms of RAM are available. For example, a static RAM (SRAM), a dynamic RAM (DRAM), a synchronous DRAM (SDRAM), a double data rate SDRAM (DDR SDRAM), an enhanced SDRAM (ESDRAM), a synchlink DRAM (SLDRAM), and a direct rambus RAM (DR RAM) can be employed.
[0080] In the above-described embodiments, all or a part can be implemented by software, hardware, firmware, or any combination thereof. When implemented as software, it can be implemented in the form of a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded into and executed by a computer, all or part of the procedures or functions according to the present application are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable apparatus. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another computer-readable storage medium.
[0081] In the description of the present specification, the description of the terms "one embodiment", "some embodiments", "an example", "a specific example", or "some examples" and the like means that the specific features, structures, materials or characteristics described in connection with the embodiment or example are included in at least one embodiment or example of the present application. Moreover, the specific features, structures, materials or characteristics described can be combined in any appropriate manner in any one or more embodiments or examples. In addition, those skilled in the art can combine and combine the different embodiments or examples described in the specification and the features of the different embodiments or examples without contradiction.
[0082] In addition, the terms "first", "second" are used only for the purpose of description, and cannot be understood as indicating or implying relative importance or implicitly indicating the number of the technical features indicated. Therefore, the features defined with "first", "second" can explicitly or implicitly include at least one of the features. In the description of the present application, the meaning of "a plurality of" is two or more, unless otherwise specifically limited.
[0083] The above is only a specific embodiment of the present application, but the protection scope of the present application is not limited thereto, and any person skilled in the art can easily think of various changes or replacements within the technical range disclosed by the present application, which should be covered within the protection scope of the present application. Therefore, the protection scope of the present application should be subject to the protection scope of the claims.< / map>
Claims
1. A method of API calling based on a meta model, characterized by, The method comprises the following steps: obtaining a custom configuration parameter of a function configuration interface; the custom configuration parameter comprises a request address, an application name, a model name, a service name, and a template code; configuring mapping between API routing and meta-model service and input parameter template of a protocol conversion layer according to the custom configuration parameter; determining an input parameter template and a protocol conversion rule according to the custom configuration parameter entered in the function configuration interface; wherein the input parameter template directly generates a default value for a non-mandatory parameter in the protocol conversion process, and the custom configuration of the input parameter template defines a template according to a parameter format of a unified API, that is, obtaining a template code in a specified format entered through the function configuration interface, identifying a placeholder in the template code in the specified format, removing the code outside the placeholder to obtain a target code, and generating an input parameter template according to the target code; obtaining an external request based on an API interface of a meta-model, and converting the external request into an internal logic parameter based on the input parameter template; the internal logic parameter comprises an application, a model, and a service; mapping a specified model and executing a corresponding service based on the internal logic parameter to obtain a return parameter; performing return protocol conversion on the return parameter based on a preconfigured output parameter template to obtain a return value in a specified format, and returning the return value through the API interface; wherein the output parameter template comprises a normal output parameter template and an abnormal output parameter template, and the protocol template for successful return and the protocol template for error return are defined through a function configuration interface to generate the corresponding normal output parameter template and abnormal output parameter template.
2. The meta-model based API calling method according to claim 1, characterized in that, The method of obtaining an external request based on an API interface of a meta-model comprises the following steps: intercepting the external request obtained from the request address of the API interface according to a preset routing strategy; distributing the intercepted external request to a request protocol conversion layer for internal protocol conversion.
3. A meta-model based API invocation system, characterized by, The method of calling an API based on a meta-model according to any one of claims 1-2 is executed.
4. An electronic device, comprising: The method comprises the following steps: a processor and a memory, the memory stores instructions, the instructions are loaded and executed by the processor to realize the method of calling an API based on a meta-model according to any one of claims 1-2.
5. A computer readable storage medium, characterized in that, The computer readable storage medium stores a computer program, and the computer program is executed by the processor to realize the method of calling an API based on a meta-model according to any one of claims 1-2.
Citation Information
Patent Citations
Processing application programming interface (API) queries based on variable schemas
US20180121261A1