A method for interface generation based on domain specific language

Abstract

The present application discloses an interface generation method, device, electronic device and readable storage medium based on a domain-specific language, which belongs to the field of microservice deployment, including: obtaining a description file of a target microservice interface; generating structured parameters of the target microservice interface according to the description file; generating deployment source code of the target microservice interface according to the structured parameters; generating execution code of the target microservice interface according to the deployment source code to obtain the target microservice interface. The present application describes the various parameters and business logic of the target microservice interface in detail through a description file with a preset structure, eliminates the inaccuracy and inconsistency of manually written interfaces, ensures the standardization and consistency of the interface definition process, and reduces the inefficiency and high error rate caused by manual participation. At the same time, it improves the versatility of the interface generation solution and solves the problem that the interface deployment efficiency and the versatility of the interface deployment process cannot be achieved at the same time.

Description

Technical Field

[0001] The present application belongs to the field of microservice deployment, and specifically relates to an interface generation method, device, electronic device and readable storage medium based on a domain-specific language. Background Art

[0002] With the popularity of microservice architecture in software development, the demand for communication between services has increased significantly. Microservice architecture splits a large application into multiple independent small services, which communicate through data interfaces to achieve functional integration and collaboration. However, as the scale and complexity of the system increase, the number and complexity of interfaces also increase.

[0003] Currently, interface development and testing usually rely on manually writing code, template engines or scripting languages, or using template engines and scripting languages ​​to generate interface code.

[0004] However, as the number of interfaces increases, the workload of manually updating interface codes is huge, which makes manual writing and maintenance of interface codes not only inefficient but also error-prone. However, the interfaces generated using existing scripting languages ​​have the defect of not being highly compatible with business requirements and being difficult to cope with complex or special business scenarios. Summary of the invention

[0005] The present application aims to provide an interface generation method, device, electronic device and readable storage medium based on a domain-specific language, which at least solves the problem that the deployment efficiency and the universality of the interface deployment process cannot be achieved simultaneously when deploying microservice interfaces.

[0006] In a first aspect, the present application discloses an interface generation method based on a domain specific language, comprising: Obtain a description file for a target microservice interface; the description file is used to describe the target microservice interface using a domain-specific language with a preset structure; Generating structured parameters of the target microservice interface according to the description file; the structured parameters include multiple deployment parameters of the target microservice interface; Generate deployment source code of the target microservice interface according to the structured parameters; According to the deployment source code, an execution code of the target microservice interface is generated to obtain the target microservice interface.

[0007] In a second aspect, the embodiment of the present application further discloses an interface generation device based on a domain specific language, comprising: A description acquisition module, used to acquire a description file of a target microservice interface; the description file is used to describe the target microservice interface in a domain-specific language with a preset structure; A parameter extraction module, used to generate structured parameters of the target microservice interface according to the description file; the structured parameters include multiple deployment parameters of the target microservice interface; A source code module, used to generate deployment source code of the target microservice interface according to the structured parameters; A deployment module is used to generate execution code of the target microservice interface according to the deployment source code to obtain the target microservice interface.

[0008] In a third aspect, an embodiment of the present application further discloses an electronic device, comprising a processor and a memory, wherein the memory stores programs or instructions that can be run on the processor, and when the program or instructions are executed by the processor, the steps of the method described in the first aspect are implemented.

[0009] In a fourth aspect, an embodiment of the present application further discloses a readable storage medium, on which a program or instruction is stored. When the program or instruction is executed by a processor, the steps of the method described in the first aspect are implemented.

[0010] In summary, in the embodiment of the present application, by obtaining a description file of a preset structure, the various parameters and business logic of the target microservice interface are described in detail, the inaccuracy and inconsistency caused by manually writing the interface definition are eliminated, and the interface definition process is ensured to be highly standardized and consistent; then, according to the structured parameters generated by the description file, the interface configuration is systematically organized, so that the generation and management of the interface becomes more efficient and orderly, ensuring that each parameter in the interface deployment process can be accurately processed, thereby avoiding errors caused by manual configuration; then, by using structured parameters to generate the deployment source code of the target microservice interface, while reducing the time and cost of manual code writing, the accuracy and consistency of the code are ensured, the syntax and logic errors introduced by manual code writing are avoided, and the interface generation process becomes more reliable; finally, the execution code of the target microservice interface is generated, which not only ensures that the final implementation of the interface has a high degree of stability and reliability, but also improves the automation level of the entire deployment process. The full process automation from source code to execution code greatly reduces the necessity of human intervention and improves the efficiency of interface deployment. Therefore, based on the method of the embodiment of the present application, while reducing the inefficiency and high error rate problems caused by manual participation, the versatility of the interface generation solution is improved, and the problem that the interface deployment efficiency and the universality of the interface deployment process cannot be achieved at the same time. BRIEF DESCRIPTION OF THE DRAWINGS

[0011] In the attached picture: Figure 1 It is a flowchart of the steps of a method for generating an interface based on a domain specific language provided in an embodiment of the present application; Figure 2 It is a flowchart of another method for generating an interface based on a domain specific language provided in an embodiment of the present application; Figure 3 It is a schematic diagram of the composition of a description file in a domain-specific language in an embodiment of the present application; Figure 4 It is a complete program running process under the embodiment of the present application; Figure 5 It is a process of generating structured data under the embodiment of the present application; Figure 6 It is a block diagram of an interface generation device based on a domain specific language provided in an embodiment of the present application; Figure 7 It is a system structure of an interface configuration and generation framework under the embodiment of the present application; Figure 8 is a block diagram of an electronic device according to an embodiment of the present application; Fig. 9 It is a block diagram of an electronic device of another embodiment provided by the embodiments of the present application. DETAILED DESCRIPTION

[0012] The following will be combined with the drawings in the embodiments of the present application to clearly and completely describe the technical solutions in the embodiments of the present application. Obviously, the described embodiments are part of the embodiments of the present application, not all of the embodiments. Based on the embodiments in the present application, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of this application.

[0013] The terms "first", "second", etc. in the specification and claims of the present application are used to distinguish similar objects, and are not used to describe a specific order or sequence. It should be understood that the data used in this way can be interchangeable under appropriate circumstances, so that the embodiments of the present application can be implemented in an order other than those illustrated or described here, and the objects distinguished by "first", "second", etc. are generally of one type, and the number of objects is not limited. For example, the first object can be one or more. In addition, "and / or" in the specification and claims represents at least one of the connected objects, and the character " / " generally indicates that the objects associated with each other are in an "or" relationship.

[0014] Figure 1 This is a method for generating an interface based on a domain specific language provided by this embodiment.

[0015] The method may include the following steps: Step 101, obtain a description file of the target microservice interface.

[0016] The description file is used to describe the target microservice interface using a domain-specific language with a preset structure.

[0017] In some embodiments of the present application, obtaining a description file for the target microservice interface is an important step to ensure the standardization and consistency of the interface generation process. This step describes the target microservice interface through a domain-specific language (DSL) with a preset structure to describe the various parameters and business logic of the interface in detail. Through this process, the inaccuracy and inconsistency caused by manually writing interface definitions can be eliminated, thereby ensuring that the interface definition process is highly standardized and consistent. A domain-specific language is a language designed specifically for a specific application domain, usually with concise syntax and specific semantics, and can effectively describe the business logic of the domain. After executing this step, accurate basic data can be provided for subsequent interface generation to ensure the efficiency and reliability of the entire process.

[0018] In a specific example, when developing an e-commerce platform in a microservice architecture, the user first obtains a description file that describes the product management service interface. This file describes the interface name, version, network path, request method, request parameters, and response format in detail using a domain-specific language. By obtaining and parsing this description file, the system can standardize and consistently define the product management service interface, ensuring that the subsequently generated interface code conforms to the expected business logic, thereby improving the efficiency and accuracy of interface generation and deployment.

[0019] Step 102: Generate structured parameters of the target microservice interface according to the description file.

[0020] The structured parameters include multiple deployment parameters of the target microservice interface.

[0021] In some embodiments of the present application, generating structured parameters of the target microservice interface according to the description file is a key step to ensure efficient and accurate interface configuration. This step extracts and organizes the various deployment parameters of the interface by parsing the description file, making the generation and management of the interface more systematic and orderly. The structured parameters include multiple deployment parameters of the target microservice interface, including but not limited to the name, version, network path, request method, request parameters, and response format of the interface. In this way, errors caused by manual configuration can be avoided, thereby ensuring that each parameter in the interface deployment process can be accurately processed.

[0022] In a specific example, when developing an order management service in a microservice architecture, the structured parameters of the order management service interface are first generated according to the description file. The description file includes the interface name "OrderService", version number "v1.0", data path " / orders", request method "POST", and request parameters including order ID, customer information, product list, etc. The system parses the description file and organizes this information into structured parameters to ensure that these parameters can be accurately referenced and processed when the interface code is generated, thereby achieving efficient and accurate interface configuration.

[0023] Step 103: Generate deployment source code of the target microservice interface according to the structured parameters.

[0024] In some embodiments of the present application, generating the deployment source code of the target microservice interface according to the structured parameters is a core step in the interface generation process. This step automatically generates the source code of the target microservice interface by using the previously generated structured parameters to ensure the accuracy and consistency of the code. The structured parameters include multiple deployment parameters of the interface, such as name, version, network path, request method, request parameters, and response format. By parsing these parameters and embedding them into a preset code template, the deployment source code can be efficiently generated, thereby greatly reducing the time and cost of manual code writing and avoiding syntax and logic errors that may be introduced by manual code writing.

[0025] In a specific example, when developing a payment service in a microservice architecture, the system automatically generates the deployment source code of the payment service based on the previously generated structured parameters (such as interface name "PaymentService", version number "v1.0", network path " / payments", request method "POST", request parameters including payment ID, amount, payment method, etc.). In this way, the system can accurately generate code that conforms to the expected business logic, greatly improving the efficiency and reliability of code generation and ensuring the stability and consistency of the interface.

[0026] Step 104: Generate execution code of the target microservice interface according to the deployed source code to obtain the target microservice interface.

[0027] In some embodiments of the present application, generating the execution code of the target microservice interface according to the deployment source code is the final step of the interface deployment process. This step automatically generates the execution code of the target microservice interface by using the previously generated deployment source code, thereby completing the final implementation of the interface. The execution code refers to the code that can be executed directly on the server or other operating environment, which contains all the necessary logic and operation instructions to ensure that the interface can work properly. By this automatic generation of the execution code, the stability and reliability of the interface can be significantly improved, the errors of human operation can be reduced, and the efficiency of interface deployment can be improved.

[0028] In a specific example, when developing an order processing service in a microservice architecture, the system automatically generates the execution code of the order processing service based on the previously generated deployment source code. The generated execution code includes a series of operation logic such as order creation, modification, and deletion, ensuring that the order processing service can work normally in the operating environment. In this way, the system can efficiently deploy the order processing service to the production environment, ensure the stability and reliability of the service, and improve the operating efficiency of the overall system.

[0029] In summary, in the embodiment of the present application, by obtaining a description file of a preset structure, the various parameters and business logic of the target microservice interface are described in detail, the inaccuracy and inconsistency caused by manually writing the interface definition are eliminated, and the interface definition process is ensured to be highly standardized and consistent; then, according to the structured parameters generated by the description file, the interface configuration is systematically organized, so that the generation and management of the interface becomes more efficient and orderly, ensuring that each parameter in the interface deployment process can be accurately processed, thereby avoiding errors caused by manual configuration; then, by using structured parameters to generate the deployment source code of the target microservice interface, while reducing the time and cost of manual code writing, the accuracy and consistency of the code are ensured, the syntax and logic errors introduced by manual code writing are avoided, and the interface generation process becomes more reliable; finally, the execution code of the target microservice interface is generated, which not only ensures that the final implementation of the interface has a high degree of stability and reliability, but also improves the automation level of the entire deployment process. The full process automation from source code to execution code greatly reduces the necessity of human intervention and improves the efficiency of interface deployment. Therefore, based on the method of the embodiment of the present application, while reducing the inefficiency and high error rate problems caused by manual participation, the versatility of the interface generation solution is improved, and the problem that the interface deployment efficiency and the universality of the interface deployment process cannot be achieved at the same time.

[0030] Figure 2 This is another method for generating an interface based on a domain-specific language provided in an embodiment of the present application.

[0031] The method may include the following steps: Step 201, obtain a description file of the target microservice interface.

[0032] The description file is used to describe the target microservice interface using a domain-specific language with a preset structure.

[0033] The method shown in this step has been explained in step 101 and will not be repeated here.

[0034] Optionally, step 201 includes the following sub-steps: Sub-step 2011, extracting the description text of the target microservice interface from the operating environment data of the server where the target microservice interface is located.

[0035] The description text is used to represent multiple configuration information of the target microservice interface.

[0036] In some embodiments of the present application, extracting the description text of the target microservice interface from the operating environment data of the server where the target microservice interface is located is a key step to ensure that the detailed interface configuration is obtained. This step extracts the description text related to the target microservice interface by scanning and parsing the operating environment data of the server, ensuring that the description text can accurately characterize multiple configuration information of the target microservice interface. Configuration information refers to various parameters and configuration settings related to the target microservice interface, including but not limited to the name, version, network path, request method, request parameters, and response format of the interface. After executing this step, a detailed data basis can be provided for the subsequent generation of description files, ensuring that the definition and configuration of the interface are more accurate and efficient.

[0037] In a specific example, when developing an order management service in a microservice architecture, the system extracts description text from the operating environment data of the server where the order management service is located. The description text includes the interface name of the order management service "OrderService", version number "v1.0", network path " / orders", request method "POST", and request parameters including order ID, customer information, and product list. By extracting this configuration information, the system can accurately characterize the various interface configurations of the order management service, provide reliable data support for generating description files, and thus improve the efficiency and accuracy of interface generation and management.

[0038] Sub-step 2012, writing the multiple configuration information in the description text into the description initialization file to obtain the description file.

[0039] The description initialization file is recorded in a domain specific language with a preset structure.

[0040] In some embodiments of the present application, writing multiple configuration information in the description text into the description initialization file is a key step to ensure that the description file is standardized and consistent. This step parses the description text and writes the configuration information contained therein into the description initialization file item by item, so that the generated description file can accurately reflect the various configurations of the target microservice interface. The description initialization file is recorded in a domain-specific language with a preset structure. The domain-specific language (DSL) is a language designed specifically for a specific application field that can effectively describe the business logic and configuration information of the field. After executing this step, an accurate and standard description file can be obtained, providing reliable data support for subsequent interface generation and configuration.

[0041] In a specific example, when developing an inventory management service in a microservice architecture, the system writes multiple configuration information from the extracted description text (such as interface name "InventoryService", version number "v1.0", URL path " / inventory", request method "GET", request parameters including inventory ID and inventory quantity, etc.) into the description initialization file one by one. The description initialization file records this configuration information through a preset domain-specific language structure, thereby generating an accurate and standardized description file. In this way, the system can ensure the standardization and consistency of the description file and improve the efficiency and accuracy of interface generation and configuration.

[0042] Optional, such as Figure 3 As shown, a specific structure of a description file described in a domain-specific language provided according to an embodiment of the present application is shown, and the information contained therein includes: Basic information: Name: the name of the target microservice interface; Version: the version number of the interface; Description: a brief description of the interface. The basic information section is used to uniquely identify and describe the target microservice interface. The name is used to distinguish different interfaces, the version number helps with version control and management, and the description provides basic information and usage of the interface, allowing developers to quickly understand the core functions and application scenarios of the interface.

[0043] Domain information: Model: Name: name of the model, Description: brief description of the model; Interface: Name: name of the interface, Description: brief description of the interface. The domain information section is used to define the business model and specific interface involved in the interface. The model section describes the structure and purpose of a specific business model, while the interface section describes the name and function of a specific business interface. This information helps ensure that the interface is closely integrated with business requirements and improves the accuracy of interface definition and business consistency.

[0044] Custom processing logic: Physical model: Name: name of the physical model, Description: brief description of the physical model; Domain model: Name: name of the domain model, Description: brief description of the domain model, Interface: Name: name of the interface, Description: brief description of the interface. The custom processing logic section allows users to define specific processing logic based on specific business needs. The physical model and domain model sections are used to define specific physical and domain models in the system, while the interface section defines specific business interfaces related to these models. This information enables the system to flexibly adjust and expand the processing logic of the interface according to user needs, enhancing the flexibility and adaptability of the system.

[0045] Field description: Field structure: Field name: the name of the field, Field type: the data type of the field; Request method: Request header: request header information, Request body: request body information, Response method: Response header: response header information, Response body: response body information. The field description part is used to define the request and response format of the interface in detail. The field structure part describes the name and data type of the specific field, and the request method and response method parts describe the header and body structure of the request and response in detail. This information ensures that the interface can accurately process input and output data, and improves the functionality and stability of the interface.

[0046] For example, you can define the interface and model parameters under DSL as follows: api_specification: name: "UserAPI" version: "1.0.0" description: "API for user management" models: UserModel: description: "Represents a user entity" The name item under the api_specification project defines the name of this group of interfaces (the interface named UserAPI), the version item defines the version of this group of interfaces (version number 1.0.0), and the description item defines the purpose of this group of interfaces (the specific purpose is API for user management, that is, the user management interface). The UserModel item under the models project defines a specific user model (defined as empty here, which can be used to indicate the use of the default user model), and the description item defines the purpose of this user model (the specific purpose is Represents auser entity, that is, a model used to represent user entities).

[0047] Depending on how the DSL defines the target microservice interface and the specific expression of the definition (such as the type of compiled code used), corresponding adjustments can be made according to the specific needs of the user and are not further limited in this application.

[0048] Step 202: Generate structured parameters of the target microservice interface according to the description file.

[0049] The structured parameters include multiple deployment parameters of the target microservice interface.

[0050] The method shown in this step has been explained in step 102 and will not be repeated here.

[0051] Optionally, step 202 includes the following sub-steps: Sub-step 2021, performing a syntax integrity check on the description file.

[0052] In some embodiments of the present application, performing a grammatical integrity check on the description file is a key step to ensure that the description file is correctly structured and free of grammatical errors. This step parses the description file to check whether it complies with preset grammatical rules, ensuring that each configuration information in the description file is defined according to the preset grammar. A grammatical integrity check is a process for verifying whether a text complies with predefined grammatical rules. By performing a grammatical integrity check, grammatical errors in the description file can be discovered and corrected, thereby improving the accuracy and reliability of the description file and ensuring that the subsequently generated structured parameters are based on the correct description file.

[0053] In a specific example, when developing an order management service in a microservice architecture, the system performs a grammatical integrity check on the description file. The description file includes information such as the interface name, version, network path, request method, and request parameters of the order management service. By parsing this information, the system checks whether the description file conforms to the preset grammatical rules, such as whether each parameter is correctly defined and whether the grammatical structure is complete. After the check is completed, if the description file conforms to the grammatical rules, it can be confirmed that there are no grammatical errors in the description file, thereby ensuring the accuracy and reliability of the subsequently generated structured parameters.

[0054] Sub-step 2022: When the description file matches a preset grammatical integrity condition, a semantic check is performed on the description file.

[0055] In some embodiments of the present application, when the description file matches the preset grammatical integrity conditions, semantic checking of the description file is a key step to ensure the logical correctness and business consistency of the description file. This step parses the content of the description file to check whether it complies with predefined semantic rules, ensuring that the semantics of each configuration information in the description file is accurate and consistent with the business logic. Semantic checking is a process of verifying whether the text content complies with business logic and semantic rules. After performing a semantic check, logical errors and inconsistencies in the description file can be discovered and corrected, thereby improving the accuracy and reliability of the description file and ensuring that the subsequently generated structured parameters are based on a correct and consistent description file.

[0056] In a specific example, when developing a payment service in a microservice architecture, the system further performs a semantic check on the description file after the description file passes the syntax integrity check. The description file includes information such as the interface name, version, network path, request method, request parameters, and response format of the payment service. By parsing this information, the system checks whether the semantics of each configuration information conforms to the business logic of the payment service, such as whether the request parameters are reasonable and whether the response format is consistent with business requirements. After the check is completed, if the description file conforms to the semantic rules, it can be confirmed that the description file logic is correct, thereby ensuring the accuracy and business consistency of the subsequently generated structured parameters.

[0057] Sub-step 2023, when the description file does not match the grammatical integrity condition, the description file is updated in response to the description supplement operation on the description file and / or according to the description file.

[0058] In some embodiments of the present application, in the case where the description file does not match the grammatical integrity condition, responding to a description supplement operation on the description file and / or updating the description file according to the description file is a remedial step to ensure the grammatical correctness of the description file. When the description file fails the grammatical integrity check, the system will perform a description supplement operation on the description file to fill in the missing information or correct the erroneous grammatical structure. After the supplement operation is completed, the system can recheck the description file based on the updated description file to ensure that the description file meets the preset grammatical integrity condition. This process improves the accuracy and completeness of the description file by correcting and supplementing the errors in the description file, and provides a reliable basis for subsequent semantic checking and structured parameter generation.

[0059] In a specific example, when developing a user management service in a microservice architecture, the system found that some configuration information in the description file was incomplete or contained grammatical errors when performing a grammatical integrity check on the description file. For example, the description file lacks a required network path configuration or the request method does not conform to the preset grammatical rules. In response to these errors, the system generates prompt information, and the user supplements and corrects the description file accordingly. After the user supplements the missing network path configuration and corrects the grammatical errors in the request method, the system re-checks the grammatical integrity based on the updated description file to ensure that the description file meets the preset grammatical conditions, providing accurate data support for subsequent processing steps.

[0060] Sub-step 2024, when the description file is characterized as a semantic match, generating structured parameters according to multiple configuration information included in the description file.

[0061] In some embodiments of the present application, when the description file is characterized as a semantic match, generating structured parameters based on multiple configuration information contained in the description file is a key step to ensure that the interface generation process is efficient and accurate. This step converts the configuration information in the description file into structured parameters by parsing the configuration information in the description file, so that the generation and management of the interface become more systematic and orderly. Structured parameters refer to configuration information organized according to a predefined structure, which contains multiple deployment parameters of the target microservice interface, including interface name, version, network path, request method, request parameters, and response format. By generating structured parameters, it can be ensured that each parameter in the interface deployment process can be accurately processed, thereby improving the efficiency and accuracy of interface generation.

[0062] In a specific example, when developing a user management service in a microservice architecture, the system generates structured parameters based on the configuration information contained in the description file after confirming the semantic match of the description file. The description file lists in detail the interface name "UserService", version number "v1.0", network path " / users", request method "POST", and request parameters including user account, user name, and email address of the user management service. The system parses this configuration information and converts it into structured parameters to ensure that these parameters can be accurately referenced and processed in the subsequent interface generation process, thereby achieving efficient and accurate interface configuration.

[0063] Step 203: Generate deployment source code of the target microservice interface according to the structured parameters.

[0064] The method shown in this step has been explained in step 103 and will not be repeated here.

[0065] Optionally, step 203 includes the following sub-steps: Sub-step 2031 : determining a target source code template corresponding to the structured parameter from among a plurality of preset source code templates.

[0066] In some embodiments of the present application, determining the target source code template corresponding to the structured parameters from a plurality of preset source code templates is a key step to ensure that the code generation process is efficient and accurate. This step enables the generated code to accurately reflect the configuration and business logic of the target microservice interface by selecting the target source code template that best suits the current structured parameters from a plurality of preset source code templates. A source code template is a predefined code structure that includes a general programming framework and logic. By using these templates, code that meets specific requirements can be quickly generated. After executing this step, the system can find the best matching source code template for each specific structured parameter, thereby greatly improving the efficiency and quality of code generation.

[0067] In a specific example, when developing an inventory management service in a microservice architecture, the system needs to select a suitable source code template based on the generated structured parameters. Assume that the structured parameters include the interface name "InventoryService", the request method "GET", the response format is JSON, etc. The system finds a target source code template specifically used to process GET requests and generate JSON responses among multiple preset source code templates. After selecting this template, the system can generate accurate deployment source code based on the structured parameters, ensuring that the code can correctly implement the functions of the inventory management service and improving the efficiency and accuracy of code generation.

[0068] Sub-step 2032, generating deployment source code according to the configuration information of the target microservice interface and the target source code template contained in the structured parameters.

[0069] In some embodiments of the present application, generating deployment source code based on the configuration information of the target microservice interface contained in the structured parameters and the target source code template is a key step in realizing the automatic generation of interface code. This step generates deployment source code that meets specific business requirements by parsing the configuration information of the target microservice interface contained in the structured parameters and inserting the configuration information into the selected target source code template. The target source code template is a predefined code structure that contains a general programming framework and logic. By combining the specific configuration information of the structured parameters, high-quality deployment source code can be quickly generated. After executing this step, the system can generate accurate deployment source code that conforms to business logic, ensuring the reliability and consistency of the interface code.

[0070] In a specific example, when developing an order management service in a microservice architecture, the system generates the deployment source code of the order management service based on the order management service interface configuration information contained in the structured parameters (such as interface name "OrderService", request method "POST", response format JSON, etc.) and the target source code template. By embedding these configuration information into the target source code template, the system automatically generates the deployment source code containing the operation logic of order creation, modification, deletion, etc., thereby ensuring that the order management service can work normally in the operating environment and realizing efficient generation and reliable deployment of interface code.

[0071] Optionally, sub-step 2032 includes the following sub-steps: Sub-step 20321, simulating the operating environment of the target microservice interface according to the environment configuration information of the target microservice interface included in the structured parameters to obtain the interface logic code of the target microservice interface.

[0072] In some embodiments of the present application, simulating the operating environment of the target microservice interface according to the environmental configuration information of the target microservice interface contained in the structured parameters is a key step to ensure the accuracy of interface logic code generation. This step simulates the operating environment of the target microservice interface by parsing the environmental configuration information in the structured parameters to ensure that the generated interface logic code is highly consistent with the actual operating environment. Environmental configuration information refers to operating environment parameters related to the target microservice interface, including server configuration, operating system, network settings, etc. After executing this step, the interface logic code that matches the actual operating environment can be obtained, thereby improving the success rate and reliability of interface deployment.

[0073] In a specific example, when developing a payment service in a microservice architecture, the system simulates the operating environment of the payment service based on the environment configuration information of the payment service interface contained in the structured parameters. The environment configuration information includes server operating system version, network protocol configuration, and storage settings. By simulating this configuration information, the system generates interface logic code that is highly consistent with the actual operating environment, ensuring that the payment service can work normally in the real operating environment, and improving the success rate and stability of interface deployment.

[0074] Sub-step 20322: Generate an interface parameter code of the target microservice interface according to the parameter configuration information of the target microservice interface included in the structured parameters.

[0075] In some embodiments of the present application, generating the interface parameter code of the target microservice interface according to the parameter configuration information of the target microservice interface contained in the structured parameters is a key step to ensure the accuracy of the interface function and configuration. This step generates the interface parameter code by parsing the parameter configuration information contained in the structured parameters to ensure that the interface can correctly process the incoming parameters and return the expected results. Parameter configuration information refers to the request and response parameter configuration related to the target microservice interface, including parameter name, type, mandatory and default value, etc. After executing this step, an interface parameter code that meets business requirements can be generated to improve the functionality and reliability of the interface.

[0076] In a specific example, when developing an inventory management service in a microservice architecture, the system generates an interface parameter code based on the parameter configuration information of the inventory management service interface contained in the structured parameters. The parameter configuration information includes the name, type (such as integer or string), mandatory field, and default value of the request parameters "inventory ID" and "inventory quantity". By parsing this configuration information, the system generates the interface parameter code of the inventory management service interface, ensuring that the service can correctly process and respond to inventory query requests, thereby improving the accuracy and availability of the interface.

[0077] Sub-step 20323, determining the deployment source code according to the interface logic code and the interface parameter code.

[0078] In some embodiments of the present application, determining the deployment source code based on the interface logic code and the interface parameter code is a key step in the interface code generation process. This step determines the final deployment source code by combining the interface logic code generated in the previous step with the interface parameter code, ensuring that the generated code can accurately reflect the functions and configurations of the target microservice interface. The interface logic code refers to the code that defines the specific behavior and business logic of the interface, while the interface parameter code contains the processing logic of the interface request and response parameters. By combining these two parts of code, a complete and fully functional deployment source code can be generated to ensure that the interface can work normally in actual operation. After executing this step, the system can generate accurate deployment source code, thereby improving the functionality and reliability of the interface code.

[0079] In a specific example, when developing an order processing service in a microservice architecture, the system first generates the interface logic code and interface parameter code for the order processing service. The interface logic code defines business operations such as order creation, modification, and deletion, while the interface parameter code handles request and response parameters such as order account, customer information, and order status. The system combines these two parts of code to determine the deployment source code of the order processing service, thereby generating a complete interface code to ensure that the order processing service can work stably in the operating environment and achieve the expected business functions.

[0080] Step 204: Match the deployment source code among multiple preset default plug-ins to obtain a target default plug-in for the deployment source code.

[0081] In some embodiments of the present application, matching the deployment source code among multiple preset default plug-ins to obtain the target default plug-in for the deployment source code is a key step to ensure that the generated source code can flexibly adapt to different business needs. A plug-in is an independent module used to extend and enhance the functionality of a software system. It can add new features to the system or improve existing features without modifying the source code. By using multiple preset default plug-ins, a variety of possible functional extensions and configuration options can be provided for the deployment source code. Through the matching process, the plug-in that best suits the current deployment source code can be automatically selected, thereby improving the efficiency of interface generation and deployment. This step ensures that the final generated interface code can better meet complex and changing business needs by improving the scalability and flexibility of the code.

[0082] In a specific example, when generating an interface for a logistics management service, the system matches the most suitable plug-in among multiple default plug-ins, such as logging plug-ins, security plug-ins, and error handling plug-ins. Through this matching process, the system automatically selects and applies these plug-ins to the deployment source code, so that the generated interface code not only has basic functions, but also can record interface call logs, perform security checks, and handle potential errors, thereby ensuring the stability and security of the interface and meeting the business needs of the logistics management service.

[0083] Step 205 : In response to the user's customizing operation on the deployment source code plug-in, a custom plug-in for the deployment source code is obtained.

[0084] In some embodiments of the present application, in response to a user's custom operation on a plug-in of the deployment source code, obtaining a custom plug-in of the deployment source code is a key step to ensure that the system can flexibly adapt to the user's specific needs. This step allows the user to customize the plug-in of the deployment source code according to specific business needs. In this way, the system can obtain the user-specified custom plug-in, thereby further enhancing the functionality and adaptability of the interface. By introducing a custom plug-in, the system can customize the behavior of the interface according to user needs, thereby ensuring that the interface can meet the requirements of specific business scenarios.

[0085] In a specific example, when developing an inventory management service in a microservice architecture, the user customizes the deployment source code according to business needs, such as adding a specific inventory verification plug-in. In response to the user's operation, the system obtains and applies the inventory verification plug-in to enhance the functionality of the interface. In this way, the generated interface code not only includes the basic inventory management functions, but also can automatically perform inventory verification according to the user's customized needs, thereby ensuring that the interface can accurately reflect the actual business logic and improve the adaptability and usability of the interface.

[0086] Step 206: Update the deployment source code according to the custom plug-in and / or the target default plug-in.

[0087] In some embodiments of the present application, updating the deployment source code according to the custom plug-in and / or the target default plug-in is an important step to ensure that the generated interface code can meet the diverse business needs. This step modifies and extends the deployment source code accordingly by combining the user-defined plug-in and the default plug-in matched by the system to enhance the functionality and adaptability of the interface code. After integrating these plug-ins, the deployment source code can provide more functional extensions and optimizations to meet the needs of different business scenarios. After executing this step, the generated interface code will have higher flexibility and maintainability, and can better adapt to complex business environments.

[0088] In a specific example, when developing a user authentication service in a microservice architecture, the system updates the deployed source code based on the custom security plug-in previously added by the user and the matching logging plug-in. In this way, the system can automatically integrate user-specific security functions and logging functions in the generated user authentication service interface code. The result is that the generated interface code can not only complete basic user authentication operations, but also has the functions of security verification and operation logging, thereby ensuring the security and traceability of the interface and meeting the specific business needs of the user authentication service.

[0089] Step 207: Generate execution code of the target microservice interface according to the deployed source code to obtain the target microservice interface.

[0090] The method shown in this step has been described in step 104 and will not be repeated here.

[0091] In summary, in the embodiment of the present application, by obtaining a description file of a preset structure, the various parameters and business logic of the target microservice interface are described in detail, the inaccuracy and inconsistency caused by manually writing the interface definition are eliminated, and the interface definition process is ensured to be highly standardized and consistent; then, according to the structured parameters generated by the description file, the interface configuration is systematically organized, so that the generation and management of the interface becomes more efficient and orderly, ensuring that each parameter in the interface deployment process can be accurately processed, thereby avoiding errors caused by manual configuration; then, by using structured parameters to generate the deployment source code of the target microservice interface, while reducing the time and cost of manual code writing, the accuracy and consistency of the code are ensured, the syntax and logic errors introduced by manual code writing are avoided, and the interface generation process becomes more reliable; finally, the execution code of the target microservice interface is generated, which not only ensures that the final implementation of the interface has a high degree of stability and reliability, but also improves the automation level of the entire deployment process. The full process automation from source code to execution code greatly reduces the necessity of human intervention and improves the efficiency of interface deployment. Therefore, based on the method of the embodiment of the present application, while reducing the inefficiency and high error rate problems caused by manual participation, the versatility of the interface generation solution is improved, and the problem that the interface deployment efficiency and the universality of the interface deployment process cannot be achieved at the same time.

[0092] like Figure 4 As shown, it is a complete process of generating a target microservice interface and finally running it according to an embodiment of the present application, which specifically completes the following steps: S1. Description file loading and parsing: Loading and parsing DSL (domain-specific language) files. The system will load and parse the DSL file that describes the target microservice interface. The DSL file contains the definition and configuration of the interface. By parsing this information, the system can obtain the specific description of the interface and generate structured data, providing a data basis for subsequent steps.

[0093] S2. Parameter verification: Verify the parameters in the structured data to ensure that all parameters meet the expected format and requirements. Parameter verification is to ensure the accuracy and consistency of the description file and avoid problems caused by parameter errors in subsequent steps.

[0094] S3. Load code templates: Load predefined code templates, which will be used to generate the code for the microservice interface. The code template contains a common programming framework and logic, and can quickly generate high-quality code by combining specific parameters in the structured data file.

[0095] S4. Scan custom processors: These processors can further process or modify the generated code. By introducing custom processors, the system can customize the interface logic according to specific needs, enhancing the flexibility and adaptability of the system.

[0096] S5. Generate code: Generate the final microservice interface code: The system generates the final microservice interface code. This step ensures that the generated code can accurately reflect the definition and configuration of the target microservice interface and has the functions required for actual operation.

[0097] S6. Code compilation and deployment: Prepare to run in the target environment. This step ensures the stability and availability of the code in actual operation, providing guarantee for the normal operation of the microservice interface.

[0098] like Figure 5 As shown, it is a process of generating structured data in the complete process of generating a target microservice interface and finally running it according to an embodiment of the present application, which specifically completes the following steps: T1. Description file loading: Load the description file that describes the target microservice interface.

[0099] In this step, the system loads the description file into memory for subsequent processing. The description file contains the definition and configuration of the interface. By loading this information, the system can obtain the specific description of the interface, ensuring that the interface definition process is highly standardized and consistent.

[0100] T2. Syntax check: Check the syntax integrity of the description file.

[0101] After loading the description file, the system performs a syntax check to ensure that each configuration information in the description file complies with the preset syntax rules. Syntax checking is used to verify the structural correctness and syntax error-freeness of the description file, thereby improving the accuracy and reliability of the description file.

[0102] T3. Semantic check: Perform semantic check on the description file.

[0103] After the description file passes the syntax check, the system performs a semantic check on it to ensure that the semantics of each configuration information is accurate and consistent with the business logic. The semantic check is used to verify the logical correctness and business consistency of the description file, thereby improving the accuracy and reliability of the description file and ensuring that the subsequently generated structured parameters are based on the correct description file.

[0104] T4. Generate structured data: Generate structured data based on the description file.

[0105] After the description file passes the syntax and semantics check, the system generates structured data based on the configuration information in the description file. Structured data refers to configuration information organized according to a predefined structure, which contains multiple deployment parameters of the target microservice interface. After generating structured data, it can ensure that every parameter in the interface deployment process can be accurately processed, thereby improving the efficiency and accuracy of interface generation.

[0106] refer to Figure 6 , which shows an interface generation device 30 based on a domain-specific language provided in an embodiment of the present application, comprising: Description acquisition module 301, used to acquire a description file of a target microservice interface; the description file is used to describe the target microservice interface using a domain-specific language with a preset structure; The parameter extraction module 302 is used to generate structured parameters of the target microservice interface according to the description file; the structured parameters include multiple deployment parameters of the target microservice interface; The source code module 303 is used to generate the deployment source code of the target microservice interface according to the structured parameters; The deployment module 304 is used to generate the execution code of the target microservice interface according to the deployment source code to obtain the target microservice interface.

[0107] Optionally, the description acquisition module 301 includes: The extraction submodule is used to extract the description text of the target microservice interface from the operating environment data of the server where the target microservice interface is located; the description text is used to characterize multiple configuration information of the target microservice interface; The writing submodule is used to write multiple configuration information in the description text into the description initialization file to obtain the description file; the description initialization file is recorded in a domain-specific language with a preset structure.

[0108] Optionally, the parameter extraction module 302 includes: The syntax check submodule is used to check the syntax integrity of the description file; The semantic checking submodule is used to perform semantic checking on the description file when the description file matches the preset grammatical integrity condition; The structured submodule is used to generate structured parameters according to multiple configuration information included in the description file when the description file is characterized as a semantic match.

[0109] Optionally, the interface generation device 30 based on a domain specific language further includes: The grammar supplement module updates the description file in response to a description supplement operation on the description file and / or according to the description file when the description file does not match the grammar integrity condition.

[0110] Optionally, the source code module 303 includes: A matching submodule, used for determining a target source code template corresponding to the structured parameter among a plurality of preset source code templates; The injection submodule is used to generate deployment source code according to the configuration information of the target microservice interface and the target source code template contained in the structured parameters.

[0111] Optionally, the injection submodule includes: A logic unit, used to simulate the operating environment of the target microservice interface according to the environment configuration information of the target microservice interface included in the structured parameters, so as to obtain the interface logic code of the target microservice interface; A parameter unit, used to generate an interface parameter code of a target microservice interface according to parameter configuration information of the target microservice interface contained in the structured parameters; The source code unit is used to determine the deployment source code according to the interface logic code and the interface parameter code.

[0112] Optionally, the interface generation device 30 based on a domain specific language further includes: The default plug-in module is used to match the deployment source code in multiple preset default plug-ins to obtain the target default plug-in for the deployment source code; A custom plug-in module, used to obtain a custom plug-in for deploying source code in response to a user's custom operation on the plug-in for deploying source code; The source code update module is used to update the deployment source code based on custom plugins and / or target default plugins.

[0113] like Figure 7 As shown, it is an interface configuration and generation framework of the interface generation system obtained based on the method provided in the embodiment of the present application, which mainly includes: Domain-specific language parser (R1): File loading component (R1.1): This component is used to load description files into the system to provide basic data for subsequent parsing and processing steps.

[0114] Domain-specific language parsing component (R1.2): responsible for parsing description files, extracting interface definitions and configuration information from the files, and ensuring that this information can be accurately understood and used by the system.

[0115] Interface Definition Generator (R2): Interface code generation component (R2.1): Generates the source code of the target microservice interface using the configuration information extracted from the description file.

[0116] Behavior simulation component (R3): This engine is used to simulate the behavior logic of the interface and generate the behavior implementation of the interface in combination with the configuration information in the description file to improve the accuracy and completeness of the interface generation.

[0117] Interface behavior simulation component (R3.1): Input and output processing subcomponent (R3.11): responsible for processing the input parameters and output results of the interface to ensure that the interface can correctly receive and respond to requests.

[0118] Error handling component (R3.12): used to capture and handle errors in interface operation to improve the stability and reliability of the system.

[0119] Logging component (R3.13): records key information during the operation of the interface to facilitate subsequent debugging and maintenance.

[0120] Plugin Manager (R4): Default plug-in component (R4.1): Provides system preset plug-ins that cover common functional requirements, such as logging, security checks, etc.

[0121] Custom plug-in components (R4.2): Allow users to customize plug-ins according to specific business needs, expand system functions, and improve the flexibility and adaptability of the interface.

[0122] In summary, in the embodiment of the present application, by obtaining a description file of a preset structure, the various parameters and business logic of the target microservice interface are described in detail, the inaccuracy and inconsistency caused by manually writing the interface definition are eliminated, and the interface definition process is ensured to be highly standardized and consistent; then, according to the structured parameters generated by the description file, the interface configuration is systematically organized, so that the generation and management of the interface becomes more efficient and orderly, ensuring that each parameter in the interface deployment process can be accurately processed, thereby avoiding errors caused by manual configuration; then, by using structured parameters to generate the deployment source code of the target microservice interface, while reducing the time and cost of manual code writing, the accuracy and consistency of the code are ensured, the syntax and logic errors introduced by manual code writing are avoided, and the interface generation process becomes more reliable; finally, the execution code of the target microservice interface is generated, which not only ensures that the final implementation of the interface has a high degree of stability and reliability, but also improves the automation level of the entire deployment process. The full process automation from source code to execution code greatly reduces the necessity of human intervention and improves the efficiency of interface deployment. Therefore, based on the method of the embodiment of the present application, while reducing the inefficiency and high error rate problems caused by manual participation, the versatility of the interface generation solution is improved, and the problem that the interface deployment efficiency and the universality of the interface deployment process cannot be achieved at the same time.

[0123] Reference Figure 8 , the electronic device 500 may include one or more of the following components: a processing component 502 , a memory 504 , a power component 506 , a multimedia component 508 , an audio component 510 , an input / output (I / O) interface 512 , a sensor component 514 , and a communication component 516 .

[0124] The processing component 502 generally controls the overall operation of the electronic device 500, such as operations associated with display, phone calls, data communications, camera operations, and recording operations. The processing component 502 may include one or more processors 520 to execute instructions to complete all or part of the steps of the above-mentioned method. In addition, the processing component 502 may include one or more modules to facilitate the interaction between the processing component 502 and other components. For example, the processing component 502 may include a multimedia module to facilitate the interaction between the multimedia component 508 and the processing component 502.

[0125] The memory 504 is used to store various types of data to support the operation of the electronic device 500. Examples of such data include instructions for any application or method operating on the electronic device 500, contact data, phone book data, messages, pictures, multimedia, etc. The memory 504 can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic memory, flash memory, magnetic disk or optical disk.

[0126] The power supply component 506 provides power to the various components of the electronic device 500. The power supply component 506 may include a power management system, one or more power supplies, and other components associated with generating, managing, and distributing power to the electronic device 500.

[0127] The multimedia component 508 includes an interface that provides an output interface between the electronic device 500 and the user. In some embodiments, the interface may include a liquid crystal display (LCD) and a touch panel (TP). If the interface includes a touch panel, the interface may be implemented as a touch screen to receive input signals from the user. The touch panel includes one or more touch sensors to sense touch, slide, and gestures on the touch panel. The touch sensor may not only sense the boundaries of the touch or slide action, but also detect the duration and pressure associated with the touch or slide operation. In some embodiments, the multimedia component 508 includes a front camera and / or a rear camera. When the electronic device 500 is in an operating mode, such as a shooting mode or a multimedia mode, the front camera and / or the rear camera may receive external multimedia data. Each front camera and rear camera may be a fixed optical lens system or have a focal length and optical zoom capability.

[0128] The audio component 510 is used to output and / or input audio signals. For example, the audio component 510 includes a microphone (MIC), and when the electronic device 500 is in an operation mode, such as a call mode, a recording mode, and a voice recognition mode, the microphone is used to receive an external audio signal. The received audio signal can be further stored in the memory 504 or sent via the communication component 516. In some embodiments, the audio component 510 also includes a speaker for outputting audio signals.

[0129] The input / output I / O interface 512 provides an interface between the processing component 502 and the peripheral interface module, which may be a keyboard, a click wheel, buttons, etc. These buttons may include but are not limited to: a home button, a volume button, a start button, and a lock button.

[0130] The sensor assembly 514 includes one or more sensors for providing various aspects of status assessment for the electronic device 500. For example, the sensor assembly 514 can detect the open / closed state of the electronic device 500, the relative positioning of components, such as the display and keypad of the electronic device 500, and the sensor assembly 514 can also detect the position change of the electronic device 500 or a component of the electronic device 500, the presence or absence of user contact with the electronic device 500, the orientation or acceleration / deceleration of the electronic device 500, and the temperature change of the electronic device 500. The sensor assembly 514 may include a proximity sensor configured to detect the presence of nearby objects without any physical contact. The sensor assembly 514 may also include an optical sensor, such as a CMOS or CCD image sensor, for use in imaging applications. In some embodiments, the sensor assembly 514 may also include an accelerometer, a gyroscope sensor, a magnetic sensor, a pressure sensor, or a temperature sensor.

[0131] The communication component 516 is used to facilitate wired or wireless communication between the electronic device 500 and other devices. The electronic device 500 can access a wireless network based on a communication standard, such as WiFi, a carrier network (such as 2G, 3G, 4G or 5G), or a combination thereof. In an exemplary embodiment, the communication component 516 receives a broadcast signal or broadcast-related information from an external broadcast management system via a broadcast channel. In an exemplary embodiment, the communication component 516 also includes a near field communication (NFC) module to facilitate short-range communication. For example, the NFC module can be implemented based on radio frequency identification (RFID) technology, infrared data association (IrDA) technology, ultra-wideband (UWB) technology, Bluetooth (BT) technology and other technologies.

[0132] In an exemplary embodiment, the electronic device 500 may be implemented by one or more application-specific integrated circuits (ASICs), digital signal processors (DSPs), digital signal processing devices (DSPDs), programmable logic devices (PLDs), field programmable gate arrays (FPGAs), controllers, microcontrollers, microprocessors, or other electronic components to implement the methods provided in the embodiments of the present application.

[0133] In an exemplary embodiment, a non-transitory computer-readable storage medium including instructions is also provided, such as a memory 504 including instructions, and the instructions can be executed by a processor 520 of an electronic device 500 to perform the above method. For example, the non-transitory storage medium can be a ROM, a random access memory (RAM), a CD-ROM, a magnetic tape, a floppy disk, an optical data storage device, etc.

[0134] Fig. 9FIG. 6 is a block diagram of an electronic device 600 according to another embodiment of the present invention. For example, the electronic device 600 may be provided as a server.

[0135] Reference Fig. 9 , the electronic device 600 includes a processing component 622, which further includes one or more processors, and a memory resource represented by a memory 632, for storing instructions that can be executed by the processing component 622, such as an application. The application stored in the memory 632 may include one or more modules, each corresponding to a set of instructions. In addition, the processing component 622 is configured to execute instructions to perform the method provided in the embodiment of the present application.

[0136] The electronic device 600 may also include a power supply component 626 configured to perform power management of the electronic device 600, a wired or wireless network interface 650 configured to connect the electronic device 600 to a network, and an input / output (I / O) interface 658. The electronic device 600 may operate based on an operating system stored in the memory 632, such as Windows Server™, Mac OS X™, Unix™, Linux™, FreeBSD™ or the like.

[0137] Those skilled in the art will readily appreciate other embodiments of the present application after considering the specification and practicing the application disclosed herein. The present application is intended to cover any modification, use or adaptation of the present application, which follows the general principles of the present application and includes common knowledge or customary techniques in the art that are not disclosed in the present disclosure. The specification and examples are intended to be exemplary only, and the true scope and spirit of the present application are indicated by the following claims.

[0138] It should be understood that the present application is not limited to the precise structures that have been described above and shown in the drawings, and that various modifications and changes may be made without departing from the scope thereof. The scope of the present application is limited only by the appended claims.

Claims

1. A method for generating an interface based on a domain specific language, characterized in that: include: Get the description file of the target microservice interface; The description file is used to describe the target microservice interface by using a domain-specific language with a preset structure; Generate structured parameters of the target microservice interface according to the description file; The structured parameters include a plurality of deployment parameters of the target microservice interface; Generate deployment source code of the target microservice interface according to the structured parameters; According to the deployment source code, an execution code of the target microservice interface is generated to obtain the target microservice interface.

2. The method for generating an interface based on a domain specific language according to claim 1, characterized in that: The obtaining of the description file of the target microservice interface includes: Extracting a description text of the target microservice interface from the operating environment data of the server where the target microservice interface is located; the description text is used to characterize multiple configuration information of the target microservice interface; The plurality of configuration information in the description text is written into a description initialization file to obtain the description file; the description initialization file is recorded in a domain specific language with a preset structure.

3. The method for generating an interface based on a domain specific language according to claim 1, characterized in that: The generating structured parameters of the target microservice interface according to the description file includes: Performing a grammatical integrity check on the description file; When the description file matches a preset grammatical integrity condition, performing a semantic check on the description file; In the case where the description file is characterized as a semantic match, the structured parameters are generated according to a plurality of configuration information included in the description file.

4. The method for generating an interface based on a domain specific language as claimed in claim 3, characterized in that: After the description file is subjected to a syntax integrity check, the interface generation method based on a domain specific language further comprises: In case the description file does not match the grammatical completeness condition, the description file is updated in response to a description supplement operation on the description file and / or based on the description file.

5. The method for generating an interface based on a domain specific language according to claim 1, wherein: The step of generating the deployment source code of the target microservice interface according to the structured parameters includes: Determining a target source code template corresponding to the structured parameter among a plurality of preset source code templates; The deployment source code is generated according to the configuration information of the target microservice interface and the target source code template contained in the structured parameters.

6. The method for generating an interface based on a domain specific language according to claim 5, characterized in that: The generating the deployment source code according to the configuration information of the target microservice interface and the target source code template contained in the structured parameters includes: According to the environment configuration information of the target microservice interface contained in the structured parameters, the operating environment of the target microservice interface is simulated to obtain the interface logic code of the target microservice interface; Generate an interface parameter code of the target microservice interface according to the parameter configuration information of the target microservice interface contained in the structured parameters; The deployment source code is determined according to the interface logic code and the interface parameter code.

7. The method for generating an interface based on a domain specific language according to claim 1, characterized in that: Before generating the execution code of the target microservice interface according to the deployment source code to obtain the target microservice interface, the interface generation method based on the domain specific language also includes: Matching the deployment source code in a plurality of preset default plug-ins to obtain a target default plug-in of the deployment source code; In response to a user's customization operation on the deployment source code plug-in, obtaining a customized plug-in for the deployment source code; The deployment source code is updated according to the custom plug-in and / or the target default plug-in.

8. An interface generation device based on a domain specific language, characterized in that: include: Description acquisition module, used to obtain the description file of the target microservice interface; The description file is used to describe the target microservice interface by using a domain-specific language with a preset structure; A parameter extraction module, used to generate structured parameters of the target microservice interface according to the description file; The structured parameters include a plurality of deployment parameters of the target microservice interface; A source code module, used to generate deployment source code of the target microservice interface according to the structured parameters; A deployment module is used to generate execution code of the target microservice interface according to the deployment source code to obtain the target microservice interface.

9. An electronic device, characterized in that: include: A processor, a memory for storing instructions executable by the processor; The processor is configured to execute the instructions to implement the method according to any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that: When the instructions in the computer-readable storage medium are executed by a processor of an electronic device, the electronic device is enabled to perform the method as claimed in any one of claims 1 to 7.

Images