Interface registration method and device, electronic equipment and storage medium

Abstract

The invention relates to the technical field of computers, and provides an interface registration method and device, electronic equipment and a storage medium. The method comprises the steps of obtaining a to-be-registered interface document submitted by an interface provider; preprocessing the to-be-registered interface document to obtain target document information; wherein the target document information at least comprises target interface information; performing information extraction on the target document information through a pre-trained information extraction model to obtain normalized interface description information; and generating routing configuration information of an application programming interface (API) gateway based on the normalized interface description information, and registering the routing configuration information to the API gateway. The application can adapt to and efficiently process different interface document formats, and automatically register to the API gateway according to the standardized interface description information obtained by processing, and manual intervention is not needed in the whole process, so that the labor cost and the time cost can be greatly saved.

Description

Technical Field

[0001] This application relates to the field of computer technology, specifically to an interface registration method, apparatus, electronic device, and storage medium. Background Technology

[0002] With the increasing prevalence of distributed architectures such as microservices and cloud-native technologies, the importance of API (Application Programming Interface) gateways as the core hub for north-south traffic in a system is self-evident. All service interfaces, whether internal or external, typically need to be registered with the gateway before they can be invoked. Therefore, the efficiency and accuracy of interface registration directly impact the agility of business systems and the development and maintenance costs.

[0003] Currently, mainstream gateway interface registration methods primarily rely on manual input and standard document import. In manual input, the interface provider needs to manually and systematically fill in detailed information such as the interface path, method, parameters, and request / response body format on the gateway's interactive page. This method is not only tedious and repetitive, but also highly susceptible to human error leading to inconsistencies between the entered information and the actual interface implementation, creating potential problems for subsequent interface calls. To improve automation, some gateways support automatic identification and registration based on standard interface documents. However, this standard document import method requires the interface provider to generate standardized documents that conform to the gateway's specific requirements beforehand. In practice, different teams and projects may use different interface document formats. To meet the gateway's import requirements, developers must perform secondary editing and format conversion of the original documents. This process essentially does not reduce manpower input; instead, it adds additional adaptation work unrelated to business development.

[0004] In summary, current technologies, whether manual data entry or standard document import, have failed to fundamentally resolve the contradiction between the diversity of interface document formats and the limited recognition capabilities of gateways. This results in significant human and time costs during the interface registration process, becoming a bottleneck for improving R&D efficiency.

[0005] Therefore, there is an urgent need in this field for an automated interface registration technology that can adapt to multiple document formats and requires no manual intervention, so as to truly achieve zero-cost automation of gateway interface registration. Summary of the Invention

[0006] This application provides an interface registration method, apparatus, electronic device, and storage medium that can adapt to and efficiently process different interface document formats, and automatically register to the API gateway based on the processed standardized interface description information. The entire process requires no manual intervention, which can greatly save manpower and time costs.

[0007] In a first aspect, embodiments of this application provide an interface registration method, including: Obtain the API documentation submitted by the API provider for the API to be registered; The interface document to be registered is preprocessed to obtain target document information; wherein, the target document information includes at least target interface information; The target document information is extracted using a pre-trained information extraction model to obtain standardized interface description information. Based on the standardized interface description information, routing configuration information for the application programming interface (API) gateway is generated, and the routing configuration information is registered to the API gateway.

[0008] In one embodiment, the preprocessing of the interface document to be registered to obtain target document information includes: Obtain the format type of the interface document to be registered; Invoke the target parser corresponding to the format type to parse the interface document to be registered and obtain the target parsing information; The target parsing information is standardized to obtain the target interface information.

[0009] In one embodiment, the target document information further includes at least one of format indication tags and format feature information, and the preprocessing of the interface document to be registered to obtain the target document information further includes: Generate the format indicator tag according to the format type of the interface document to be registered; and / or, The format features are extracted from the interface document to be registered to obtain the format feature information, which includes at least one of the following: heading level, number of tables, number of code blocks, tag structure, and model definition.

[0010] In one embodiment, the information extraction model is trained in the following manner: Obtain the training sample interface document, and preprocess the training sample interface document to obtain the training sample document information; Obtain the normalized interface description information of the training samples corresponding to the training sample interface document, and construct a training sample set based on the normalized interface description information and the training sample document information; The information extraction model is obtained by fine-tuning the large language model using the training sample set.

[0011] In one embodiment, after fine-tuning the large language model using the training sample set to obtain the information extraction model, the method further includes: Obtain a test sample set; wherein the test sample set includes test sample interface documents in various formats and their corresponding standardized interface description information, and the test sample set contains at least one interface document format type that does not appear in the training sample set; The performance of the information extraction model is tested using the test sample set. If the test passes, the information extraction model is considered to have completed training.

[0012] In one embodiment, generating routing configuration information for the Application Programming Interface (API) gateway based on the standardized interface description information and registering the routing configuration information to the API gateway includes: Based on the standardized interface description information, generate the routing configuration information for the APISIX gateway; The routing configuration information is written into the distributed key-value storage system etcd; The APISIX gateway listens for configuration changes of preset prefixes in etcd and dynamically loads the routing configuration information to complete interface registration.

[0013] In one embodiment, after generating routing configuration information for the Application Programming Interface (API) gateway based on the standardized interface description information and registering the routing configuration information to the API gateway, the method further includes: Receive a test command triggered by a user, and obtain the Uniform Resource Identifier (URI) of the interface to be tested based on the test command; A test request is sent to the proxy address of the API gateway based on the URI to verify whether the interface registration is effective; and / or, The API gateway receives call requests from clients triggered by registered interfaces; The call request is authorized and verified; the authorization verification includes at least one of API key authentication, JSON network token authentication, and Open Authorization 2.0 authentication. Upon successful verification, the call request is forwarded to the corresponding backend service, which then executes the business logic of the interface call.

[0014] Secondly, embodiments of this application provide an interface registration apparatus, comprising: The document retrieval module is used to retrieve the API documentation to be registered submitted by the API provider. A preprocessing module is used to preprocess the interface document to be registered to obtain target document information; wherein, the target document information includes at least target interface information; The information extraction module is used to extract information from the target document information using a pre-trained information extraction model to obtain standardized interface description information. The interface registration module is used to generate routing configuration information for the application programming interface (API) gateway based on the standardized interface description information, and register the routing configuration information to the API gateway.

[0015] Thirdly, embodiments of this application provide an electronic device, including a memory, a processor, and a computer program stored in the memory and running on the processor, wherein the processor executes the computer program to implement the interface registration method described in the first aspect.

[0016] Fourthly, embodiments of this application provide a non-transitory computer-readable storage medium storing a computer program thereon, which, when executed by a processor, implements the interface registration method described in the first aspect.

[0017] The interface registration method, apparatus, electronic device, and storage medium provided in this application, after obtaining the interface document to be registered submitted by the interface provider, first preprocesses the interface document to obtain target document information, wherein the target document information includes at least target interface information. Then, through a pre-trained information extraction model, information is extracted from the target document information to obtain standardized interface description information. In this way, the interface provider does not need to learn complex gateway configuration syntax; they only need to submit their original interface documents from daily development. This application embodiment can automatically and accurately preprocess and extract information from the interface documents to obtain standardized interface description information. Next, based on the standardized interface description information, routing configuration information for the API gateway is generated, and the routing configuration information is registered to the API gateway to achieve automatic interface registration. Through the above methods, this embodiment of the application can adapt to and efficiently process different interface document formats, and automatically register them to the API gateway based on the standardized interface description information obtained from the processing, thereby realizing automatic interface registration. Compared with the existing technology of registering interfaces through manual input or import of standard documents, this embodiment of the application does not require manual intervention throughout the process, which can greatly save manpower and time costs, thereby improving the efficiency of microservice integration. Attached Figure Description

[0018] To more clearly illustrate the technical solutions in this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0019] Figure 1This is one of the flowcharts illustrating the interface registration method provided in the embodiments of this application; Figure 2 This is a second flowchart illustrating the interface registration method provided in the embodiments of this application; Figure 3 This is the third flowchart illustrating the interface registration method provided in the embodiments of this application; Figure 4 This is a schematic diagram of the interface registration device provided in the embodiments of this application; Figure 5 This is a schematic diagram of the structure of the electronic device provided in the embodiments of this application. Detailed Implementation

[0020] To make the objectives, technical solutions, and advantages of this application clearer, the technical solutions of this application will be clearly and completely described below with reference to the accompanying drawings of the embodiments. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0021] With the increasing prevalence of distributed architectures such as microservices and cloud-native technologies, the importance of API (Application Programming Interface) gateways as the core hub for north-south traffic in a system is self-evident. All service interfaces, whether internal or external, typically need to be registered with the gateway before they can be invoked. Therefore, the efficiency and accuracy of interface registration directly impact the agility of business systems and the development and maintenance costs.

[0022] Currently, mainstream gateway interface registration methods primarily rely on manual input and standard document import. In manual input, the interface provider needs to manually and systematically fill in detailed information such as the interface path, method, parameters, and request / response body format on the gateway's interactive page. This method is not only tedious and repetitive, but also highly susceptible to human error leading to inconsistencies between the entered information and the actual interface implementation, creating potential problems for subsequent interface calls. To improve automation, some gateways support automatic identification and registration based on standard interface documents. However, this standard document import method requires the interface provider to generate standardized documents that conform to the gateway's specific requirements beforehand. In practice, different teams and projects may use different interface document formats. To meet the gateway's import requirements, developers must perform secondary editing and format conversion of the original documents. This process essentially does not reduce manpower input; instead, it adds additional adaptation work unrelated to business development.

[0023] In summary, current technologies, whether manual data entry or standard document import, have failed to fundamentally resolve the contradiction between the diversity of interface document formats and the limited recognition capabilities of gateways. This results in significant human and time costs during the interface registration process, becoming a bottleneck for improving R&D efficiency.

[0024] Furthermore, while some existing more automated solutions attempt to generate interface code using machine learning models, their model training heavily relies on a dataset consisting of a specific format of interface documentation, the content of that documentation, and the corresponding interface code. This approach faces significant challenges in gateway application scenarios: firstly, obtaining a large amount of standardized interface code as training samples is extremely difficult; secondly, the mandatory requirement to provide both the interface code and the specific format documentation severely limits the solution's versatility. For interface providers who only possess the original interface documentation, this solution is difficult to implement and cannot be widely applied.

[0025] Therefore, there is an urgent need in this field for an automated interface registration technology that can adapt to multiple document formats and requires no manual intervention, so as to truly achieve zero-cost automation of gateway interface registration.

[0026] Based on the above, this application proposes an interface registration method, apparatus, electronic device, and storage medium, which are described below in conjunction with... Figures 1-5 Describe it.

[0027] Figure 1 This is one of the flowcharts illustrating the interface registration method provided in this application embodiment. (Refer to...) Figure 1 This application provides an interface registration method, which includes steps S110, S120, S130 and S140.

[0028] Step S110: Obtain the interface document to be registered submitted by the interface provider.

[0029] In this embodiment, the interface registration method is applied to an electronic device that has an interface registration system. The interface registration system adopts a front-end / back-end separation architecture, logically divided into three core parts: a user front-end, a service back-end, and an API gateway.

[0030] The user frontend, built using modern frameworks such as Vue, provides interactive interfaces, including a southbound API registration interface and a northbound API call interface. Users upload API documentation and initiate registration requests for new APIs through the southbound API registration interface. Users perform functional testing and call verification of registered APIs through the northbound API call interface.

[0031] In the service backend, an automatic registration module is built using an information extraction model. This model, trained on a large language model, extracts information from the input target document to obtain standardized interface description information, which is then automatically registered to the gateway. A management module is built using the Spring Boot framework. This module provides a standard RESTful API (Representational State Transfer Application Programming Interface) to the user frontend, handles all management requests, receives the interface documents to be registered uploaded by the user frontend, calls the automatic registration module for information extraction, generates routing configuration information for the API gateway based on the standardized interface description information, and registers this routing configuration information to the API gateway.

[0032] The API gateway automatically registers APIs by monitoring configuration changes in the configuration center and loading new routing rules in real time without loss. It also provides request forwarding functionality, routing northbound call requests matching registered API paths to the corresponding backend services. Furthermore, it offers call authorization capabilities, integrating multiple authentication methods to perform identity authentication and access control before forwarding northbound call requests.

[0033] API providers upload their API documentation to be registered through an interactive interface built with the Vue framework; this documentation is referred to as the API documentation to be registered. This API documentation to be registered can be in any format, such as Markdown, HTML, XML, Swagger, Word, or PDF.

[0034] Correspondingly, the system receives the interface document to be registered and then executes the automated interface registration process.

[0035] Step S120: Preprocess the interface document to be registered to obtain target document information; wherein, the target document information includes at least target interface information.

[0036] The target documentation information should include at least the target interface information, including but not limited to: interface name, request address, request method, request parameters, response format, and remarks.

[0037] The target interface information is obtained as follows: obtain the format type of the interface document to be registered; call the target parser corresponding to the format type to parse the interface document to be registered and obtain the target parsing information; perform standardization processing on the target parsing information to obtain the target interface information.

[0038] Furthermore, the target document information also includes at least one of format indication tags and format feature information.

[0039] The format indicator tag is obtained as follows: the format indicator tag is generated according to the format type of the interface document to be registered.

[0040] The format feature information is obtained as follows: format features are extracted from the interface document to be registered to obtain format feature information. The format feature information includes at least one of the following: heading level, number of tables, number of code blocks, tag structure, and model definition.

[0041] The specific process for obtaining the aforementioned target document information can be found in the following embodiments, which will not be elaborated here.

[0042] Step S130: Extract information from the target document information using a pre-trained information extraction model to obtain standardized interface description information.

[0043] The target document information is constructed into a prompt word, which is then input into a pre-trained information extraction model. The information extraction model extracts information from the target document information, resulting in standardized interface description information output by the information extraction model.

[0044] Among them, the information extraction model is obtained by fine-tuning the large language model through the training sample set, and is used to accurately extract structured interface description information from unstructured target document information.

[0045] Standardized interface description information, that is, structured interface description information, can be output in JSON format.

[0046] For example, the API documentation to be registered is a Markdown document, as follows: #User Login ## Interface Description Used for user authentication.

[0047] ##ask Method: POST Path: / api / v1 / login ## Request Body json { "username":"string", "password":"string" } The target interface information obtained after parsing is as follows: "User login, Interface description, Used for user authentication, Request, Method: POST, Path: / api / v1 / login, Request body {"username":"string","password":"string"}".

[0048] The prompt words are as follows: "Please extract the API information from the following text and output it in JSON format, containing an array of name, url, method, and parameters (including username and password fields): [Target API Information]" The prompt words are input into the information extraction model, and the output is as follows: json { "name": "User Login", "description": "Used for user authentication." "path": " / api / v1 / login", "method": "POST", "requestBody": { "type": "object", "properties": { "username": { "type": "string"}, "password": { "type": "string"} }, "required": ["username", "password"] } } Step S140: Based on the standardized interface description information, generate routing configuration information for the application programming interface (API) gateway, and register the routing configuration information to the API gateway.

[0049] The standardized interface description information is mapped to a JSON format of route configuration that the API gateway can recognize, and then the route configuration information is registered with the API gateway.

[0050] API gateways include, but are not limited to: APISIX gateway, Kong gateway, and Envoy gateway.

[0051] In one implementation, if the API gateway is an APISIX gateway, the standardized interface description information is first mapped to a routing configuration JSON format that the APISIX gateway can recognize; then, the routing configuration information is written to the / apisix / routes / directory of etcd (a distributed key-value store system); then, the APISIX gateway listens for configuration changes of the / apisix / routes / prefix in etcd and dynamically loads the routing configuration information to complete the interface registration.

[0052] In another implementation, if the API gateway is a Kong gateway, the standardized interface description information is first mapped to JSON format for Services and Routes that the Kong gateway can recognize. Then, the Kong Admin API (management API, default port 8001) is called via HTTP request to create the corresponding Services and Routes. Kong updates this configuration to its underlying database (such as PostgreSQL). All Kong nodes in the cluster synchronize this configuration from the database through round-robin or cache invalidation mechanisms, thereby completing the interface registration.

[0053] The interface registration method provided in this application, after obtaining the interface document to be registered submitted by the interface provider, first preprocesses the interface document to obtain target document information, wherein the target document information includes at least target interface information. Then, through a pre-trained information extraction model, information is extracted from the target document information to obtain standardized interface description information. In this way, the interface provider does not need to learn complex gateway configuration syntax; it only needs to submit its original interface document from daily development. This application embodiment can automatically and accurately preprocess and extract information from the interface document to obtain standardized interface description information. Next, based on the standardized interface description information, routing configuration information for the API gateway is generated and registered to the API gateway to achieve automatic interface registration. Through this method, this application embodiment can adapt to and efficiently process different interface document formats and automatically register the interface to the API gateway based on the processed standardized interface description information, achieving automatic interface registration. Compared with existing technologies that use manual input or standard document import for interface registration, this application embodiment requires no manual intervention throughout the process, greatly saving labor and time costs, thereby improving the efficiency of microservice integration.

[0054] Based on any of the above embodiments Figure 2 This is the second flowchart illustrating the interface registration method provided in this application embodiment. (Refer to...) Figure 2 Step S120 may include: step S121, step S122, and step S123.

[0055] Step S121: Obtain the format type of the interface document to be registered.

[0056] The format type can be identified by the file extension. For example, when the file extension is .md, the format type is markdown; when the file extension is .docx, the format type is Word.

[0057] Step S122: Call the target parser corresponding to the format type to parse the interface document to be registered and obtain target parsing information.

[0058] By using a parser mapping table, the target parser corresponding to the format type is invoked to parse the interface document to be registered, obtaining the target parsing information. By utilizing the parser, the original text can be accurately extracted from interface documents of different formats, laying the foundation for subsequent unified processing.

[0059] Specifically, it can call the markdown-it parser to parse markdown documents, the Beautiful Soup parser to process HTML and XML document parsing, the swagger-parser parser to parse Swagger specifications, the PDF Box parser to parse PDF documents, and the Apache POI parser to parse Word and Excel documents.

[0060] The target parsing information includes, but is not limited to: interface name, request address (URL), request method, request parameters, response format, and remarks.

[0061] For example, if the interface document to be registered is in markdown format, the markdown-it parser is called to convert the markdown syntax into a standard HTML document object model (DOM), and the resulting target parsing information is an HTML DOM tree.

[0062] For example, if the interface document to be registered is a Word document containing tables with three columns: parameter name, type, and description, the Apache POI parser can be called to traverse the paragraphs and tables in the document, read the text content in the cells, and then output the target parsing information as follows: { "paragraphs": ["..."], "tables": [ [["parameter name","type", "description"], ["userId", "integer", "user ID"]] ]}.

[0063] Step S123: Standardize the target parsing information to obtain the target interface information.

[0064] The target parsing information is standardized by converting the target parsing information, which is output by each parser in different forms, into a unified, plain text or simple structured intermediate representation, which is the target interface information.

[0065] It should be understood that different standardized processing methods should be adopted for different types of target parsing information.

[0066] For example, for the HTML DOM tree obtained from parsing a Markdown document, traverse the DOM tree, ignore all style tags, extract only the content of all text nodes, and concatenate them into a string in the original order to obtain the document content: "Request URL / api / v1 / users Request method GET...".

[0067] For example, the system flattens the target parsing information extracted from Word. For instance, it converts table data into descriptive text. In the example above, the table data is converted to: "Parameter List: Parameter Name: userId, Type: Integer, Description: User ID", and then the output is a long plain text string concatenated from all paragraph text and the converted table text, which is the target interface information.

[0068] Standardization eliminates the heterogeneity of input data caused by different source formats. Regardless of the document's complexity, this step transforms it into a relatively uniform intermediate representation focused on semantic content. This greatly simplifies the inference task of subsequent information extraction models, which no longer need to understand the specific output formats of various parsers; they can focus solely on extracting semantic information from the text (i.e., the target interface information).

[0069] The interface registration method provided in this application calls a target parser corresponding to the format type of the interface document to be registered, parses the document to obtain target parsing information, and then standardizes the target parsing information to obtain target interface information. This method transforms interface documents with varying formats into a unified text representation, eliminating the interference of format heterogeneity on subsequent models and allowing them to focus on understanding the text semantics themselves. Furthermore, the extracted clean and structured text content significantly improves the accuracy and reliability of subsequent information extraction models, effectively solving the core problem of interface document format diversity and laying a solid data foundation for the entire automated interface registration process. In addition, this method gives the system strong scalability; when new interface document formats need to be supported, only a new mapping relationship needs to be added to the parser registry without modifying the core process.

[0070] Based on any of the above embodiments, the target document information further includes at least one of format indication tags and format feature information, and step S120 may further include: step S124 and / or step S125.

[0071] Step S124: Generate the format indicator tag according to the format type of the interface document to be registered.

[0072] During preprocessing, the system adds metadata to the data, specifically a format indicator tag. This tag is used to explicitly inform the model of the format of the interface document to be registered, enabling it to draw on learning experience for that format, thereby performing more accurate parsing. At the same time, it also improves the accuracy and robustness of the model when switching between different formats.

[0073] Specifically, the format indicator tag is generated based on the format type of the interface document to be registered.

[0074] Furthermore, when inputting target document information into the model, format indicator tags can be appended to the beginning of the target interface information before inputting it into the model.

[0075] For example, for a Markdown document, the system will generate the tag "[FORMAT:markdown]", and the corresponding model input will be "[FORMAT:markdown], {target interface information}".

[0076] Step S125: Extract format features from the interface document to be registered to obtain the format feature information. The format feature information includes at least one of the following: heading level, number of tables, number of code blocks, tag structure, and model definition.

[0077] When extracting format features, the format features to be extracted can be determined based on the format type of the interface document to be registered, and then the format feature information can be extracted from the interface document to be registered based on the determined format features.

[0078] For example, for a Markdown document, its heading levels, number of code blocks, and number of tables can be extracted; for an HTML document, its tag structure can be extracted; and for an OpenAPI document, its model definition can be extracted.

[0079] Furthermore, after extracting the format feature information, this feature information can be quantified to form a feature vector, which is then concatenated with the target interface information and format indicator label before being input into the model.

[0080] For example, for a Markdown document, the Abstract Syntax Tree (AST) is traversed, the number of heading nodes at different levels is counted, and the maximum depth is calculated as the heading level feature. In this example, assuming there is one H1 and one H2, the maximum depth is determined to be 2. The number of code block nodes is counted as the code block quantity feature, which is assumed to be 1 in this example. Simultaneously, the number of nodes containing table structures is counted as the table quantity feature; in this example, assuming there is one parameterized table. Based on the format feature information extracted above, the generated feature vector is [2,1,1] (a numerical array).

[0081] By extracting quantitative meta-information about the organizational structure of the interface documents to be registered, and using this information as a supplement to the information extraction model input, the model can be provided with contextual clues about the document structure, helping the model to more quickly locate the areas where key information is located and understand the layout logic of the document.

[0082] The interface registration method provided in this application provides more information to the information extraction model by generating format indication tags and / or extracting format feature information and using them as a supplement to the input of the information extraction model. This significantly improves the accuracy and robustness of information extraction when the information extraction model is faced with interface documents with complex formats and irregular layouts.

[0083] Based on any of the above embodiments Figure 3 This is the third flowchart illustrating the interface registration method provided in this application's embodiments. (Refer to...) Figure 3 The training steps for the information extraction model include: step S10, step S20 and step S30.

[0084] Step S10: Obtain the training sample interface document, preprocess the training sample interface document to obtain training sample document information.

[0085] Collect interface documents in different formats as training sample interface documents.

[0086] Then, the training sample interface documents are preprocessed to obtain document information, denoted as training sample document information. The training sample document information includes at least the interface document content, denoted as training sample interface document content.

[0087] The method for obtaining the training sample interface document content can refer to the method for obtaining target document information described above. That is, obtain the format type of the training sample interface document, call the corresponding parser to parse the training sample interface document, and then perform standardization processing to obtain the training sample interface document content.

[0088] Furthermore, the training sample document information may also include at least one of format indicator tags and format feature information. The acquisition process can refer to the processing of the interface documents to be registered described above, and will not be repeated here. By providing format indicator tags, the information extraction model can identify and utilize specific patterns of different formats during the learning process, thereby enabling more targeted parsing of document content in subsequent applications, significantly improving the accuracy and robustness of information extraction. Simultaneously, by providing deep format feature information, the model is endowed with structural analysis capabilities, allowing it to maintain high recognition accuracy even when processing documents with irregular layouts or sparse information distribution in subsequent applications, further enhancing the system's adaptability and reliability.

[0089] It should be noted that by using format indicator labels as auxiliary information, the understanding of specific formats can be enhanced through multi-task learning or additional classification heads when training the information extraction model.

[0090] Step S20: Obtain the normalized interface description information of the training samples corresponding to the training sample interface document, and construct the training sample set based on the normalized interface description information and the training sample document information.

[0091] Professionals annotate each training sample interface document with corresponding standardized interface description information based on a predefined JSON Schema, which is denoted as the training sample standardized interface description information.

[0092] Then, the training sample document information is used as input data, and the normalized interface description information of the training samples is used as annotation data to construct the training sample set.

[0093] Step S30: Fine-tune the large language model using the training sample set to obtain the information extraction model.

[0094] Supervised learning is employed, using a general, pre-trained Large Language Model (LLM) as a foundation, fine-tuned with a prepared training sample set. In each training iteration, input data is fed into the LLM, and the normalized interface description information output by the LLM (denoted as predicted normalized interface description information) is compared with the labeled data (i.e., the actual normalized interface description information). The loss is calculated, and the model parameters are updated through backpropagation. Through this method, the model learns the mapping rules from messy unstructured text to well-structured JSON.

[0095] Furthermore, a multi-task learning mechanism can be introduced during model training. In addition to the output layer for the main task (generating and predicting normalized interface description information), a small, parallel neural network layer is added to perform the auxiliary task—predicting the format of the input interface document. During training, the losses from both the main and auxiliary tasks jointly affect the model's updates. This approach forces the model to simultaneously learn to understand content and recognize format, prompting it to learn more general and powerful feature representations, thereby enhancing its generalization ability.

[0096] The interface registration method provided in this application embodiment can train an information extraction model through the above method for subsequent information extraction.

[0097] Based on any of the above embodiments, after step S30, the method further includes steps S40, S50, and S60.

[0098] Step S40: Obtain a test sample set; wherein the test sample set includes test sample interface documents in various formats and their corresponding standardized interface description information, and the test sample set contains at least one interface document format type that does not appear in the training sample set.

[0099] After obtaining the information extraction model through initial fine-tuning using the training sample set, the information extraction model can be further tested to assess its intelligence and generalization ability.

[0100] The test can be divided into basic performance evaluation and format migration capability verification.

[0101] For basic performance evaluation, test sample interface documents in various formats can be constructed, with the same format type as the training sample set, to evaluate the model's performance under different formats.

[0102] To test format transferability, test sample interface documents can be constructed in a format different from that of the training sample set. That is, their format type must be different from any format type in the training sample set to examine whether the model can transfer knowledge learned from one format to another. For example, if the training sample set only uses Markdown and Microsoft Word format interface documents, then a new format type, such as HTML format interface documents, will be introduced into the test sample set.

[0103] It should be noted that after constructing the test sample interface document, the test sample interface document is preprocessed to obtain document information, denoted as test sample document information. This test sample document information includes at least the interface document content, denoted as test sample interface document content, and may also include at least one of format indicator tags and format feature information.

[0104] It should be understood that these test sample interface documents also correspond to manually pre-annotated, correct standardized interface description information of the test samples as annotation data.

[0105] The test sample set is constructed by using the test sample document information as input data and the standardized interface description information of the test sample as annotation data.

[0106] Step S50: The information extraction model is tested using the test sample set.

[0107] In step S60, if the test passes, the training of the information extraction model is deemed complete.

[0108] The test sample document information from the constructed test sample set is input into the information extraction model obtained by the above fine-tuning. The model performs information extraction processing and outputs the predicted normalized interface description information. Then, it is automatically compared with the normalized interface description information of the test samples to calculate performance indicators such as precision and recall.

[0109] The calculated performance metrics are compared with preset performance thresholds. If the calculated performance metrics are greater than the preset thresholds, the information extraction model is considered to have completed training and can be deployed to the production environment for automated interface registration. If the calculated performance metrics are less than or equal to the preset thresholds, the information extraction model is considered to have failed training and needs to be retrained.

[0110] The interface registration method provided in this application can verify the intelligence and generalization ability of the information extraction model through the above-mentioned method, thereby filtering out unqualified models and ensuring that the models finally put into use have strong adaptability and robustness. This ensures the long-term stable service quality of the entire automated registration system from the source and reduces the subsequent maintenance costs caused by insufficient model capabilities.

[0111] Based on any of the above embodiments, step S140 includes: step S141, step S142 and step S143.

[0112] Step S141: Based on the standardized interface description information, generate the routing configuration information for the APISIX gateway.

[0113] This application provides an efficient and dynamic interface registration implementation scheme based on a specific technology stack (APISIX+etcd).

[0114] If the API gateway is an APISIX gateway, first map the standardized interface description information into a JSON format for route configuration that the APISIX gateway can recognize. For example, generate a JSON object containing URI (path), methods, upstream (upstream service address), and plugin configuration.

[0115] In this way, the general standardized interface description information can be transformed into specific instructions that the target gateway (APISIX gateway) can directly understand and execute.

[0116] Step S142: Write the routing configuration information into the distributed key-value storage system etcd.

[0117] Then, the generated routing configuration information is written to etcd as a key-value pair. This key-value pair is usually stored in etcd under a predefined directory prefix specific to APISIX, such as / apisix / routes / . The complete key for a specific route might be / apisix / routes / 1, where 1 is the route ID (identifier).

[0118] Step S143: Monitor the configuration changes of the preset prefix in etcd through the APISIX gateway, and dynamically load the routing configuration information to complete the interface registration.

[0119] The APISIX gateway's worker process establishes a persistent connection with etcd upon startup, continuously monitoring all configuration changes to its default prefix (e.g., / apisix / routes). When a new route configuration is written to etcd, etcd pushes this configuration change event to the APISIX node in real time. Upon receiving the notification, the APISIX node immediately retrieves the details of the route configuration from etcd and dynamically loads it into its in-memory routing table. This entire process does not require restarting the gateway service. At this point, the registration process for this interface is complete, and it can immediately receive external traffic.

[0120] The interface registration method provided in this application, by utilizing the native deep integration of the APISIX gateway and the etcd configuration center, achieves real-time awareness and dynamic loading of configuration changes, solving the problem that traditional gateway registration requires restarting or reloading to take effect. It is particularly suitable for cloud-native microservice architecture scenarios with extremely high requirements for availability and agility.

[0121] Based on any of the above embodiments, after step S140, the method may further include steps S150 and S160.

[0122] Step S150: Receive a test command triggered by the user, and obtain the Uniform Resource Identifier (URI) of the interface to be tested based on the test command.

[0123] In this embodiment, after the interface is successfully registered with the API gateway, the system will provide a test button for the interface on the front-end interface. Clicking this test button will trigger a test command. Correspondingly, the back-end service will receive the test command and then obtain the interface's URI (Uniform Resource Identifier).

[0124] Step S160: Send a test request to the proxy address of the API gateway based on the URI to verify whether the interface registration is effective.

[0125] Then, the backend service constructs an HTTP request (i.e., a test request) and sends it directly to the proxy address of the API gateway. Then, based on the response returned by the API gateway, it determines whether the interface has been correctly routed by the gateway.

[0126] The interface registration method provided in this application embodiment, when tested in the above manner, can promptly detect anomalies in the registration process, prevent defective configurations from entering the production environment, thereby improving system reliability and user experience.

[0127] Based on any of the above embodiments, after step S140, the steps S170, S180, and S190 may also be included.

[0128] Step S170: Receive a call request from a client triggered by a registered interface through the API gateway.

[0129] Step S180: Perform authorization verification on the call request; the authorization verification includes at least one of API key authentication, JSON network token authentication and Open Authorization 2.0 authentication.

[0130] External clients can initiate call requests based on the registered interface information. Correspondingly, the API gateway will receive the call request and initiate the authorization verification process. Specifically, the API gateway will perform one or more of the following verifications based on the pre-configured authorization policy for the interface: (1) API key authentication: Check whether the request header (such as X-API-Key) contains a valid, pre-distributed key and verify whether the key has permission to access this interface.

[0131] (2) JWT (JSON Web Token) authentication: Parse request headers (such as Authorization: Bearer) <token>The JWT token in the token is used to verify its digital signature, validity period, and the scope of permissions declared in the token.

[0132] (3) OAuth (Open Authorization) 2.0 authentication: The request is redirected to a third-party authentication server (such as Authing, Okta). After the user completes the authorization, the access token carried in the callback is verified.

[0133] Step S190: When the verification is successful, the call request is forwarded to the corresponding backend service so that the business logic of the interface call can be executed through the backend service.

[0134] Once verification is successful, the API gateway forwards the request to the corresponding backend service. The backend service receives the request, executes the specific business logic of the API call (such as database queries and business calculations), and generates response data. Finally, the response is returned to the external client through the API gateway.

[0135] When authentication fails, the API gateway will directly return a 401 Unauthorized or 403 Forbidden status code to the external client, blocking the access.

[0136] The interface registration method provided in this application, upon receiving a call request, first authorizes and verifies it through an API gateway. Only after successful verification can the call request be forwarded to the corresponding backend service. This approach effectively prevents unauthorized access and malicious attacks, meeting the API security requirements of enterprise applications, while avoiding the duplication of security logic in each backend service, thus simplifying the architecture.

[0137] The interface registration apparatus provided in the embodiments of this application is described below. The interface registration apparatus described below and the interface registration method described above can be referred to in correspondence.

[0138] Figure 4 This is a schematic diagram of the interface registration device according to an embodiment of this application, with reference to... Figure 4 This application embodiment also provides an interface registration device, which may include: a document acquisition module 410, a preprocessing module 420, an information extraction module 430, and an interface registration module 440; wherein: The document acquisition module 410 is used to acquire the interface documents to be registered submitted by the interface provider; The preprocessing module 420 is used to preprocess the interface document to be registered to obtain target document information; wherein, the target document information includes at least target interface information; The information extraction module 430 is used to extract information from the target document information using a pre-trained information extraction model to obtain standardized interface description information. The interface registration module 440 is used to generate routing configuration information for the application programming interface (API) gateway based on the standardized interface description information, and register the routing configuration information to the API gateway.

[0139] The interface registration apparatus provided in this application, after obtaining the interface document to be registered submitted by the interface provider, first preprocesses the interface document to obtain target document information, wherein the target document information includes at least target interface information. Then, through a pre-trained information extraction model, information is extracted from the target document information to obtain standardized interface description information. In this way, the interface provider does not need to learn complex gateway configuration syntax; it only needs to submit its original interface document from daily development. This application embodiment can automatically and accurately preprocess and extract information from the interface document to obtain standardized interface description information. Next, based on the standardized interface description information, routing configuration information for the API gateway is generated, and the routing configuration information is registered to the API gateway to achieve automatic interface registration. In this way, this application embodiment can adapt to and efficiently process different interface document formats and automatically register the interface to the API gateway based on the processed standardized interface description information, achieving automatic interface registration. Compared with existing technologies that use manual input or standard document import for interface registration, this application embodiment requires no manual intervention throughout the process, greatly saving labor and time costs, thereby improving the efficiency of microservice integration.

[0140] It should be noted that the interface registration device provided in this application embodiment can implement all the method steps implemented in the above method embodiment and can achieve the same technical effect. Here, the parts that are the same as those in the method embodiment and the beneficial effects will not be described in detail.

[0141] Figure 5 An example is a schematic diagram of the physical structure of an electronic device, such as... Figure 5 As shown, the electronic device may include a processor 510, a communication interface 520, a memory 530, and a communication bus 540, wherein the processor 510, the communication interface 520, and the memory 530 communicate with each other through the communication bus 540. The processor 510 can call logical instructions in the memory 530 to execute the interface registration method provided in the above embodiments.

[0142] Furthermore, the logical instructions in the aforementioned memory 530 can be implemented as software functional units and, when sold or used as independent products, can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or a portion of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0143] On the other hand, embodiments of this application also provide a non-transitory computer-readable storage medium storing a computer program thereon, which, when executed by a processor, is implemented to perform the interface registration methods provided in the above embodiments.

[0144] The device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs. Those skilled in the art can understand and implement this without any creative effort.

[0145] Through the above description of the embodiments, those skilled in the art can clearly understand that each embodiment can be implemented by means of software plus necessary general-purpose hardware platforms, and of course, it can also be implemented by hardware. Based on this understanding, the above technical solutions, in essence or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product can be stored in a computer-readable storage medium, such as ROM / RAM, magnetic disk, optical disk, etc., and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute the methods described in the various embodiments or some parts of the embodiments.

[0146] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application.< / token>

Claims

1. An interface registration method, characterized by, The method comprises the following steps: An acquisition interface provides a to-be-registered interface document submitted by an interface provider; The to-be-registered interface document is preprocessed to obtain target document information; wherein the target document information at least comprises target interface information; An information extraction model pre-trained is used to perform information extraction on the target document information to obtain standardized interface description information; Based on the standardized interface description information, routing configuration information of an application programming interface (API) gateway is generated, and the routing configuration information is registered to the API gateway.

2. The interface registration method of claim 1, wherein, The preprocessing of the to-be-registered interface document to obtain the target document information comprises the following steps: The format type of the to-be-registered interface document is acquired; A target parser corresponding to the format type is called to parse the to-be-registered interface document to obtain target parsing information; The target parsing information is standardized to obtain the target interface information.

3. The interface registration method of claim 1, wherein, The target document information further comprises at least one of a format indication label and format feature information; the preprocessing of the to-be-registered interface document to obtain the target document information further comprises the following steps: The format indication label is generated according to the format type of the to-be-registered interface document; and / or Format features are extracted from the to-be-registered interface document to obtain the format feature information; the format feature information comprises at least one of title level, table quantity, code block quantity, label structure and model definition.

4. The interface registration method according to any one of claims 1 to 3, characterized in that, The information extraction model is trained in the following manner: Training sample interface documents are acquired, and the training sample interface documents are preprocessed to obtain training sample document information; Training sample standardized interface description information corresponding to the training sample interface documents is acquired, and a training sample set is constructed according to the training sample standardized interface description information and the training sample document information; The training sample set is used to fine-tune a large language model to obtain the information extraction model.

5. The interface registration method of claim 4, wherein, After the training sample set is used to fine-tune the large language model to obtain the information extraction model, the following steps are further included: A test sample set is acquired; wherein the test sample set comprises test sample interface documents in multiple formats and corresponding test sample standardized interface description information, and the test sample set contains at least one interface document format type that does not appear in the training sample set; The test sample set is used to test the performance of the information extraction model; When the test is passed, it is determined that the training of the information extraction model is completed.

6. The interface registration method according to any one of claims 1 to 3, wherein, The generation of the routing configuration information of the API gateway based on the standardized interface description information, and the registration of the routing configuration information to the API gateway, comprises the following steps: The routing configuration information of an APISIX gateway is generated based on the standardized interface description information; The routing configuration information is written into a distributed key-value storage system etcd; The APISIX gateway listens to the configuration changes of a preset prefix in the etcd, dynamically loads the routing configuration information, and completes the registration of the interface.

7. The interface registration method according to any one of claims 1 to 3, characterized by, The method further comprises: receiving a test instruction triggered by a user, obtaining a uniform resource identifier (URI) of an interface to be tested based on the test instruction; sending a test request to a proxy address of the API gateway based on the URI to verify whether the interface registration is effective; and / or, receiving, through the API gateway, a call request triggered by a client based on the registered interface; performing authorization verification on the call request, the authorization verification comprising at least one of API key authentication, JSON web token authentication, and open authorization 2.0 authentication; when the verification is passed, forwarding the call request to a corresponding backend service to execute business logic of the interface call through the backend service.

8. An interface registration apparatus characterized by comprising: The method comprises: a document obtaining module configured to obtain an interface provider-submitted interface document to be registered; a preprocessing module configured to preprocess the interface document to be registered to obtain target document information, wherein the target document information at least comprises target interface information; an information extraction module configured to extract information from the target document information by using a pre-trained information extraction model to obtain normalized interface description information; an interface registration module configured to generate routing configuration information of an application programming interface (API) gateway based on the normalized interface description information, and register the routing configuration information to the API gateway.

9. An electronic device comprising a memory, a processor, and a computer program stored on the memory and running on the processor, characterized in that, The processor executes the computer program to implement the interface registration method in any one of claims 1 to 7.

10. A non-transitory computer-readable storage medium having stored thereon a computer program, characterized in that, The computer program is executed by the processor to implement the interface registration method in any one of claims 1 to 7.

Images