Method and apparatus for processing API interface code

Abstract

The application discloses a kind of API interface code processing method and device.The method comprises the following steps of: obtaining API interface initial code, wherein API interface initial code is the function code required for the API interface code to be generated;From a plurality of data models, a target data model matching the API interface initial code is obtained, wherein the target data model includes the information of the processing mode for the target data structure, and the target data structure is the data structure of the data to be interacted with the API interface code to be generated;Target code is generated based on the target data model, wherein the target code is used to process the target data structure;API interface code is determined according to API interface initial code and target code.The application solves the technical problem that in the related art, API interface code needs to parse data model to process interactive data when running, thereby affecting system performance.

Description

Technical Field

[0001] This invention relates to the field of API interfaces, and more specifically, to a method and apparatus for processing API interface code. Background Technology

[0002] With the continuous development of technology, many servers now offer an open API (Application Program Interface) for third-party clients or websites to call, achieving effects such as rapid information sharing, improved system flexibility, and scalability. However, the API interface code in these technologies needs to parse the data model at runtime to effectively process the interactive data, thus impacting system performance.

[0003] There is currently no effective solution to the above problems. Summary of the Invention

[0004] This invention provides a method and apparatus for processing API interface code, which at least solves the technical problem in related technologies that API interface code needs to parse data models to process interactive data during runtime, thereby affecting system performance.

[0005] According to one aspect of the present invention, a method for processing API interface code is provided, comprising: obtaining initial API interface code, wherein the initial API interface code is the functional code required for the API interface code to be generated; obtaining a target data model matching the initial API interface code from a plurality of preset data models, wherein the target data model includes information on the processing method for a target data structure, and the target data structure is the data structure of the data interacted by the API interface code to be generated; generating target code based on the target data model, wherein the target code is used to process the target data structure; and determining the API interface code according to the initial API interface code and the target code.

[0006] Furthermore, the target data structure includes the data structure of multiple fields in the data. The processing method of the API interface code also includes: parsing the target data model to obtain the field path and field description information matching each field. The field description information includes at least the basic type and attribute information of the field. The attribute information is used to characterize the processing method of the field's data structure. For each field, an index relationship is established between the field path and the field description information. A metadata group is generated based on the field paths, field description information, and index relationships of all fields. The target code is generated based on the metadata group.

[0007] Furthermore, the target data model contains multiple scopes, which are determined based on the nesting relationships between multiple fields. The API interface code processing method further includes: for the first target scope in the multi-level scope, determining the field path of the field in the first target scope based on the path of the first target scope and the field identifier of the field in the first target scope; for the field in the first target scope, determining the basic type and attribute information of the field from the first target scope, and determining the field description information of the field based on the basic type and attribute information; determining whether the field nests other fields, where other fields refer to fields other than the first target scope; if the field nests other fields, determining that the other fields belong to the first scope, and determining the field path and field description information of the other fields from the first scope, where the first scope is a scope in the multi-level scope that is different from the first target scope; repeatedly executing the step of determining whether other fields nest other fields until it is determined that other fields do not nest other fields.

[0008] Furthermore, the API interface code processing method also includes: determining whether the field description information contains target attribute information, wherein the target attribute information is used to indicate field path transformation of the field, and the target attribute information includes the transformed field path; if the field description information contains target attribute information, determining the information in the field description information other than the target attribute information as the target field description information; if the field description information does not contain target attribute information, determining the field description information as the target field description information; establishing an index relationship between the field path of the field and the target field description information to obtain a first index relationship, and if the field description information contains target attribute information, establishing an index relationship between the field path of the field and the field path in the target attribute information to obtain a second index relationship, wherein the first index relationship and the second index relationship constitute an index relationship.

[0009] Furthermore, the metadata group includes a first metadata group, a second metadata group, and a third metadata group. The second index relationship includes a first sub-index relationship for indexing field paths in target attribute information based on field paths, and a second sub-index relationship for indexing field paths in target attribute information based on field paths. The API interface code processing method further includes: generating the first metadata group based on the field paths of all fields, the target field description information of all fields, and the first index relationship of all fields; generating the second metadata group based on the field paths of fields with target attribute information, the target attribute information, and the first sub-index relationship, wherein the data in the second metadata group is used by the API interface code to process the first data, which refers to the data sent from the first end to the second end, where the first end is the client and the second end is the server running the API interface code; and generating the third metadata group based on the field paths of fields with target attribute information, the target attribute information, and the second sub-index relationship, wherein the data in the third metadata group is used by the API interface code to process the second data, which refers to the data to be sent from the second end to the first end.

[0010] Furthermore, the API interface code processing method also includes: after determining the API interface code based on the API interface initial code and the target code, constructing the API interface based on the API interface code. The target code contains a first code generated based on the first metadata group and a second code generated based on the second metadata group. When the API interface receives the first data, it processes the fields in the first data according to the first code. If there is an index relationship in the second code that matches the fields in the processed first data, then the fields in the processed first data are converted according to the matching index relationship to obtain the converted first data. The converted first data is used by the API interface initial code to execute the target function.

[0011] Furthermore, the API interface code processing method also includes: during the process of the API interface processing fields in the first data according to the first code, for the second target scope in the first data, determining the actual field path of the field in the second target scope according to the second target scope; if the target field description information is indexed from the first code according to the actual field path, the field is processed according to the indexed target field description information, and if the processing result indicates that the field does not have any anomalies, it is determined whether the field is nested with other fields; if the field is nested with other fields, it is determined that the other fields belong to the second scope, and the step of determining the actual field path of other fields according to the second scope is repeated until the processing result indicates that the field has any anomalies or it is determined that the other fields are not nested with fields other than other fields, wherein the second scope is a scope in the first data that is different from the second target scope.

[0012] Furthermore, the API interface code processing method also includes: after obtaining the target data model that matches the initial API interface code from multiple preset data models, generating the API documentation corresponding to the API interface code based on the target data model.

[0013] Furthermore, the API interface code processing method also includes: defining annotations in the initial API interface code and referencing the target data model in the annotations, wherein the annotations are used by the API documentation generation tool to read the content in the annotations; using the API documentation generation tool to read the target data model referenced by the annotations and generating a target file based on the target data model, wherein the target file is a file in the target format; and using the API documentation generation tool to perform visualization processing on the data in the target file to obtain the API documentation.

[0014] According to another aspect of the present invention, an API interface code processing apparatus is also provided, comprising: a first acquisition module, configured to acquire initial API interface code, wherein the initial API interface code is the functional code required by the API interface code to be generated; a second acquisition module, configured to acquire a target data model matching the initial API interface code from a plurality of preset data models, wherein the target data model includes information on the processing method for a target data structure, and the target data structure is the data structure of the data interacted by the API interface code to be generated; a first generation module, configured to generate target code based on the target data model, wherein the target code is used to process the target data structure; and a processing module, configured to determine the API interface code based on the initial API interface code and the target code.

[0015] According to another aspect of the present invention, a computer-readable storage medium is also provided, wherein a computer program is stored in the computer-readable storage medium, and the computer program is configured to execute the processing method of the above-described API interface code at runtime.

[0016] According to another aspect of the present invention, an electronic device is also provided, the electronic device including one or more processors; a memory for storing one or more programs, wherein when the one or more programs are executed by the one or more processors, the one or more processors implement a method for running the programs, wherein the programs are configured to execute the processing method of the above-described API interface code at runtime.

[0017] In this embodiment of the invention, a method is adopted to generate target code based on a data model and then generate API interface code based on the target code. The method involves obtaining the initial API interface code, then obtaining the target data model that matches the initial API interface code from a set of multiple preset data models, and then generating the target code based on the target data model. Thus, the API interface code is determined based on the initial API interface code and the target code. The initial API interface code is the functional code required by the API interface code to be generated. The target data model includes information on the processing method for the target data structure. The target data structure is the data structure of the data that the API interface code to be generated interacts with. The target code is used to process the target data structure.

[0018] In the above process, by generating target code based on the data model and then generating API interface code based on the target code, the API interface code can directly process the data structure of the interactive data through the target code when it is used. This reduces the impact on system performance and avoids the system performance loss caused by the API interface code needing to parse the data model to process the interactive data at runtime, as is the case in related technologies.

[0019] Therefore, the solution provided in this application achieves the goal of generating target code based on the data model and generating API interface code based on the target code, thereby reducing the impact on system performance. It also solves the technical problem in related technologies where API interface code needs to parse the data model to process interactive data during runtime, thus affecting system performance. Attached Figure Description

[0020] The accompanying drawings, which are included to provide a further understanding of the invention and form part of this application, illustrate exemplary embodiments of the invention and, together with their description, serve to explain the invention and do not constitute an undue limitation thereof. In the drawings:

[0021] Figure 1 This is a schematic diagram of an optional API interface code processing method according to an embodiment of the present invention;

[0022] Figure 2 This is a schematic diagram illustrating an optional method for generating API interface code according to an embodiment of the present invention;

[0023] Figure 3 This is a schematic diagram of an optional API interface for processing first data according to an embodiment of the present invention. Figure 1 ;

[0024] Figure 4 This is a schematic diagram of an optional API interface for processing second data according to an embodiment of the present invention. Figure 1 ;

[0025] Figure 5 This is a schematic diagram of an optional API interface for processing first data according to an embodiment of the present invention. Figure 2 ;

[0026] Figure 6 This is a schematic diagram of an optional API interface for processing second data according to an embodiment of the present invention. Figure 2 ;

[0027] Figure 7 This is a schematic diagram illustrating an optional processing method for the target API interface code according to an embodiment of the present invention;

[0028] Figure 8 This is a schematic diagram of an optional method for generating API documentation according to an embodiment of the present invention;

[0029] Figure 9 This is a schematic diagram of an optional API interface code processing device according to an embodiment of the present invention;

[0030] Figure 10 This is a schematic diagram of an optional electronic device according to an embodiment of the present invention. Detailed Implementation

[0031] To enable those skilled in the art to better understand the present invention, the technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings of the embodiments of the present invention. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of the present invention.

[0032] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this invention are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of the invention described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover a non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0033] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties. Furthermore, the collection, use and processing of the relevant data must comply with the relevant laws, regulations and standards of the relevant regions, and corresponding operation portals are provided for users to choose to authorize or refuse.

[0034] Example 1

[0035] According to an embodiment of the present invention, an embodiment of a method for processing API interface code is provided. It should be noted that the steps shown in the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions. Furthermore, although a logical order is shown in the flowchart, in some cases, the steps shown or described may be executed in a different order than that shown here.

[0036] Figure 1 This is a schematic diagram illustrating an optional API interface code processing method according to an embodiment of the present invention, such as... Figure 1 As shown, the method includes the following steps:

[0037] Step S101: Obtain the initial code of the API interface, wherein the initial code of the API interface is the functional code required by the API interface code to be generated.

[0038] Optionally, electronic devices, application systems, servers, and other devices can be used as the execution subject of this application. In this embodiment, the target processing system is used as the execution subject to obtain the initial API interface code. The initial API interface code specifies the target data model it matches. Furthermore, different target data models can be specified based on different methods within the initial API interface code. These methods include, but are not limited to, adding, deleting, modifying, and querying. The aforementioned functional code can be the business function code corresponding to the business that the generated API interface code needs to implement.

[0039] Step S102: Obtain the target data model matching the initial code of the API interface from multiple preset data models. The target data model includes information on the processing method for the target data structure. The target data structure is the data structure of the data interacted by the API interface code to be generated.

[0040] Optional, Figure 2 This is a schematic diagram of an optional method for generating API interface code according to an embodiment of the present invention, such as... Figure 2As shown, the target processing system can determine the identifier of the specified target data model from the API interface initial code during the compilation and packaging process, and then obtain the target data model from multiple preset data models based on this identifier. The target data model can be a PHP (Hypertext Preprocessor) based data model.

[0041] Step S103: Generate target code based on the target data model, wherein the target code is used to process the target data structure.

[0042] Optional, such as Figure 2 As shown, the target data structure includes the data structure of multiple fields in the data. The target processing system can parse the target data model to obtain the field paths and field description information of each field, and then generate target code based on the parsed data. The field description information includes at least the basic type and attribute information of the field. The basic type includes, but is not limited to, string, int, boolean, array, and object types. One class represents one object type. The attribute information is used to characterize the processing method of the field's data structure. The data structure includes, but is not limited to, basic type and data format. The processing method includes, but is not limited to, data validation and data conversion. The target code can be PHP code.

[0043] Step S104: Determine the API interface code based on the API interface initial code and target code.

[0044] Optional, such as Figure 2 As shown, after obtaining the target code, the target processing system can generate the target code into the API interface initial code and directly assign values ​​when defining variables (such as class attributes) to obtain the API interface code. This allows the API interface code to directly process the target data structure through the target code and execute the corresponding business functions based on the processed data through the API interface initial code.

[0045] If there are multiple initial API interface codes, the target processing system can generate target code corresponding to each initial API interface code, thereby generating API interface code corresponding to each initial API interface code.

[0046] Based on the scheme defined in steps S101 to S104 above, it can be understood that in this embodiment of the invention, the method of generating target code based on data model and generating API interface code based on target code is adopted. This involves obtaining initial API interface code, then obtaining a target data model matching the initial API interface code from a set of multiple preset data models, and then generating target code based on the target data model. Thus, the API interface code is determined based on the initial API interface code and the target code. The initial API interface code is the functional code required by the API interface code to be generated. The target data model includes information on the processing method for the target data structure. The target data structure is the data structure of the data interacted by the API interface code to be generated. The target code is used to process the target data structure.

[0047] In the above process, by generating target code based on the data model and then generating API interface code based on the target code, the API interface code can directly process the data structure of the interactive data through the target code when it is used. This reduces the impact on system performance and avoids the system performance loss caused by the API interface code needing to parse the data model to process the interactive data at runtime, as is the case in related technologies.

[0048] Therefore, the solution provided in this application achieves the goal of generating target code based on the data model and generating API interface code based on the target code, thereby reducing the impact on system performance. It also solves the technical problem in related technologies where API interface code needs to parse the data model to process interactive data during runtime, thus affecting system performance.

[0049] In one optional embodiment, the target data structure includes the data structure of multiple fields in the data. During the generation of target code based on the target data model, the target processing system can parse the target data model to obtain the field path and field description information matching each field. Then, for each field, an index relationship is established between the field path and the field description information. Next, a metadata group is generated based on the field paths, field description information, and index relationships of all fields, thereby generating the target code based on the metadata group. The field description information includes at least the basic type and attribute information of the field, and the attribute information is used to characterize the processing method of the field's data structure.

[0050] This document describes an optional target data model. The target data model includes information on how to process the data structure of multiple fields in the data. Specifically, the target data model includes the basic type and attribute information of each field. Each field has its attribute information defined above it using "#[OA\Property]". This attribute information contains multiple sub-attributes, which are sub-attribute identifiers and their corresponding values. The basic type of the field includes, but is not limited to, string, int, boolean, array, and object types. The method for validating and converting the basic type of the field can be defined as sub-attribute information within "#[OA\Property]", or it can be predefined in the initial API code. Alternatively, some content can be defined in the initial API code, and some content can be defined within "#[OA\Property]". Furthermore, the method of validating and converting the basic type of the field can be further divided based on the type of data interacted by the API interface code. The data interacted by the API interface code can be divided into first data and second data. First data refers to the data sent from the first end to the second end. The first end is the client, and the second end is the server running the API interface code. Second data refers to the data to be sent from the second end to the first end.

[0051] For example, if the basic type is string, then for the first data, the validation and conversion method for the basic type of the field is as follows: Data validation: String must be configured, otherwise an error will be reported. Furthermore, if the attribute information contains the sub-attribute "minLength", the string length cannot be less than the value of minLength, otherwise an error will be reported. If the attribute information contains the sub-attribute "maxLength", the string length cannot be greater than the value of maxLength, otherwise an error will be reported. Data conversion: No conversion is performed. For the second data, the validation and conversion method for the basic type of the field is as follows: Data validation: No validation is performed. Data conversion: Convert to string.

[0052] If the basic data type is numeric, then for the first data, the validation and conversion method for the basic data type of the field is as follows: Data validation: Numeric must be configured, otherwise an error will be reported. When the attribute information has the sub-attribute "minimum", the number cannot be less than the value of minimum, otherwise an error will be reported. When the attribute information has the sub-attribute "maximum", the number cannot be greater than the value of maximum, otherwise an error will be reported. Data conversion: No conversion is performed. For the second data, the validation and conversion method for the basic data type of the field is as follows: Data validation: No validation is performed. Data conversion: Convert to numeric.

[0053] If the basic type is Boolean, then for the first data, the validation and conversion method for the basic type of the field is as follows: Data validation: must be configured as true or false, otherwise an error will be reported; Data conversion: true is converted to 1, false is converted to 0. For the second data, the validation and conversion method for the basic type of the field is as follows: Data validation: no validation is performed; Data conversion: 1 is converted to true, 0 is converted to false.

[0054] If the basic type is an array, then for the first data, the basic type validation and conversion method for the field is as follows: Data validation: An array with numeric keys must be configured; otherwise, an error will occur. Data conversion: No conversion is performed. For the second data, the basic type validation and conversion method for the field is as follows: Data validation: No validation is performed. Data conversion: If the data is not an array with numeric keys, it is converted to an array with numeric keys by enclosing it in square brackets; otherwise, no conversion is performed. For array types, after the basic type validation passes, the system will continue to loop through and validate and convert the child elements in the data. If the basic type of a child element is an object type, the system will recursively validate and convert the child fields under that child element.

[0055] If the basic type is an object type, then for the first set of data, the basic type validation and conversion method for the field is as follows: Data validation: The configured key name must not be a number, otherwise an error will be reported; Data conversion: No conversion is performed. For the second set of data, the basic type validation and conversion method for the field is as follows: Data validation: No validation is performed; Data conversion: No conversion is performed. For object types, after the basic type validation passes, the validation and conversion of sub-fields under the object type will continue recursively.

[0056] Optionally, the following sub-properties can be defined in "#[OA\Property]" for data validation of the basic type of the field: minLength (representing the minimum length of the string), maxLength (representing the maximum length of the string), minimum (representing the minimum value of the number), and maximum (representing the maximum value of the number). Among them, minLength and maxLength take effect when the basic type is string, and minimum and maximum take effect when the basic type is int.

[0057] Optionally, a sub-attribute "format" can be defined within "#[OA\Property]". "format" indicates the data format validation and conversion performed on the field, and its value represents the method used for this validation and conversion. When "format" is defined in the field's attribute information, basic data type validation and conversion are performed first, followed by data format validation and conversion. Furthermore, the method for validating and converting the field's data format can be further refined based on the type of data interacted with by the API interface code.

[0058] For example, if the data format is IPv4, then for the first data, the data format validation and conversion method for the field is as follows: when the basic type is string, a string in the format "ABCD" must be configured, otherwise an error will be reported; when the basic type is int, a number between 0 and 4294967295 must be configured, otherwise an error will be reported; data conversion: based on the extended parameter formatType, it is determined to convert to a number between 0 and 4294967295 (formatType = int) or to a string in the format "ABCD" (formatType = string); for the second data, the data format validation and conversion method for the field is as follows: data validation: no validation; data conversion: when the basic type is string, it is converted to a string in the format "ABCD", and when the basic type is int, it is converted to a number between 0 and 4294967295.

[0059] If the data format is netmask, then for the first data, the data format validation and conversion method for the field is as follows: Data validation: When the basic type is string, a string in the format "ABCD" must be configured, otherwise an error will be reported; when the basic type is int, a number between 0 and 32 must be configured, otherwise an error will be reported; Data conversion: Based on the extended parameter formatType, it is determined whether to convert to a number between 0 and 32 (formatType = int) or to a string in the format "ABCD" (formatType = string); For the second data, the data format validation and conversion method for the field is as follows: Data validation: No validation is performed; Data conversion: When the basic type is string, it is converted to a string in the format "ABCD"; when the basic type is int, it is converted to a number between 0 and 32.

[0060] If the data format is IPv6, then for the first data, the data format validation and conversion method for the field is as follows: Data validation: IPv6 format string must be configured, otherwise an error will be reported; Data conversion: Convert to the simplest IPv6 format string; For the second data, the data format validation and conversion method for the field is as follows: Data validation: No validation; Data conversion: No conversion.

[0061] If the data format is prefix-length, then for the first data, the data format validation and conversion method for the field is as follows: Data validation: When the basic type is string, the number 0-128 must be configured to be converted to string, otherwise an error will be reported; when the basic type is int, the number between 0-128 must be configured, otherwise an error will be reported; Data conversion: No conversion is performed. For the second data, the data format validation and conversion method for the field is as follows: Data validation: No validation is performed; Data conversion: When the basic type is string, it is converted to a number between 0-128 and then to string; when the basic type is int, it is converted to a number between 0-128.

[0062] If the data format is domain, then for the first data, the data format validation and conversion method for the field is as follows: Data validation: A valid domain name string must be configured, otherwise an error will be reported; Data conversion: No conversion is performed. For the second data, the data format validation and conversion method for the field is as follows: Data validation: No validation is performed; Data conversion: No conversion is performed.

[0063] If the data format is "password (extended)," then for the first data, the data format validation and conversion method for the field is as follows: POST configuration: Data validation: The string must be decryptable according to certain rules (either asymmetric or symmetric), and the basic type validation must be normal after decryption; otherwise, an error will be reported; Data conversion: Decrypt, and determine which underlying rule to use for secondary encryption based on the extended parameters (formatType=aes, no secondary encryption is performed by default); For the second data, the data format validation and conversion method for the field is as follows: Data validation: No validation; Data conversion: No conversion.

[0064] Optionally, under format, other methods for validating and converting the data format of the field can be defined, and a parameter isPost can be defined in this method. The value of the parameter isPost is determined according to the data type (first data or second data) of the data exchanged by the API interface code, so as to determine the method for validating and converting the data format of the field based on the data type of the exchanged data.

[0065] Optionally, a sub-attribute "pattern" can also be defined in "#[OA\Property]". The sub-attribute "pattern" represents the regular expression validation of the field. The value of "pattern" is used to describe the data format constraints of the string type field. If the regular expression validation fails, an error will be reported.

[0066] Optionally, a sub-attribute "enum" can be defined within "#[OA\Property]". The sub-attribute "enum" represents the enumeration validation of the field. The value of the sub-attribute "enum" is the enumerated value of the current field. (The sub-attribute "enum" is effective when the basic types are string, int, and bool). For example, for the first data, the corresponding processing method is: Data validation: must be within the enumeration range, otherwise an error will be reported; Data conversion: no conversion is performed. For the second data, the corresponding processing method is: Data validation: no validation is performed; Data conversion: no conversion is performed. In this process, after validating the enumerated value of the current field, further validation and conversion of the basic type and data format of the current field are performed.

[0067] Optionally, sub-properties such as "default", "description", "example", "items", "formatType", "enableReturn", "onlySet", "correspondingKey", "reindex", "netmask", and "prefixLength" can also be defined in "#[OA\Property]". Among them, "default" is used to define the default value of the field, "description" is used to describe the description information of the current field, "example" is used to set the value of the current field displayed in the API documentation, and "items" is used to define the basic type of each element of the array when the basic type of the current field is array. In addition, sub-properties that can be defined in "#[OA\Property]" can also be defined in "items", except for the correspondingKey property. "formatType" indicates that after the field is validated and converted based on "format", further transformation is performed on the data. The value of "formatType" indicates the required transformation method, such as "formatType = int" indicating conversion to a numeric type. "enableReturn" defines whether to return the current field if it has a value when the data is secondary data. For example, if "enableReturn = true", it returns the value; if "enableReturn = false", it does not. "onlySet" defines whether to use a set method instead of an unset method when restoring the current field to its default value. The "unset" method refers to restoring the current field's value to the value sent by the client. The "unset" method restores the current field's value to the value defined by the "default" attribute. "correspondingKey" indicates a field path transformation. The value of "correspondingKey" is the transformed field path, which can be a relative or absolute path. Specifically, when the data is the first type of data, the field path defined in the target data model needs to be converted to the field path specified by "correspondingKey". When the data is the second type of data, the field path specified by "correspondingKey" needs to be converted to the field path defined in the target data model."reindex" specifies the index field to be renamed. "netmask" takes effect when the current field's format is for IPv4. "netmask" specifies the mask field; for example, when the data is the first data entry, the current field will be converted based on the mask field value. For instance, "5.5.5.5" (IPv4) is converted to "5.5.5.0" by mask 24. "prefixLength" takes effect when the current field's format is IPv6 and specifies the prefix length field. For instance, when the data is the first data entry, the current field will be converted based on the prefix length field value. For instance, "3333:3333:3333::3333" (IPv6) is converted to "3333:3333:3333::3333" by mask 64.

[0068] Optionally, when the basic type of a field is an object type, a portion of the field's attribute information can be defined using "#[OA\Schema]". In "#[OA\Schema]", the following three sub-attributes can be configured: (1) required: This defines the index node attributes under the current object (i.e., the field whose basic type is an object type). In simpler terms, it defines the fields that are allowed to be nested under the current object. Fields not defined in required will cause an error when appearing in the first data and will be filtered when appearing in the second data. (2) description: This describes the current object. (3) format: This defines the data validation and conversion methods for the current object. The parameter isPost can also be defined under this "format" sub-attribute. When both the object and its fields define the "format" sub-attribute, the field's "format" sub-attribute has higher priority. Furthermore, the target data model supports inheriting fields of the parent class's object type, inheriting the "required", "description", and "format" sub-attributes in the parent class's "#[OA\Schema]", and shared objects.

[0069] The target processing system can parse the aforementioned target data model to obtain the field paths and field descriptions for each field. For example, the target processing system can determine the field paths based on the nesting relationships between fields, obtain the attribute information of the fields from "#[OA\Schema]" and "#[OA\Property]", and determine the basic types of the fields from the target data model based on the field identifiers and the sentences used to describe the basic types of the fields.

[0070] Optional, such as Figure 2As shown, after determining the field paths and field descriptions for each field, the target processing system can establish an index relationship between the field paths and the field descriptions. Based on the field paths, field descriptions, and index relationships of all fields, a metadata group is generated. The target code is then generated using code generation software based on the metadata group. The metadata group is used to index the field descriptions based on the field paths and index relationships.

[0071] The following describes an optional process for generating target code based on metadata sets. The target processing system can use code generation software to create an instance object based on the `ClassType` class. The metadata set is then added to this instance object using the `addProperty` method of the `ClassType` instance object. Next, an instance object based on the `PhpNamespace` class is created, specifying the namespace. This instance object's `addClass` method imports the `ClassType` instance object. Finally, the target code is obtained by echoing the `PhpNamespace` instance object and stored in the target storage area, which can be a specified PHP file. The `addProperty` method adds properties to the instance object, the `addClass` method adds one or more classes to selected elements, and `echo` outputs text or variable values ​​to the terminal or command-line interface.

[0072] Furthermore, an optional process for introducing target code into the API interface initialization code is described. The target processing system can parse the API interface initialization code to obtain an AST (Abstract Syntax Tree), add a constructor to the obtained AST, and introduce the target code's class into the AST, resulting in a modified AST. Then, the modified AST is converted back into code (e.g., PHP code), thus obtaining the API interface code. The constructor specifies that the initial values ​​of attribute variables in the API interface initialization code are instances of the target code class. Optionally, the constructor can also specify that the initial values ​​of different attribute variables under different states (CRUD operations) in the API interface initialization code are instances of the corresponding target code class.

[0073] For example, the target processing system can parse the initial code of the API interface, obtain the AST tree, and create an instance object based on the Node\Stmt\ClassMethod class. When creating this instance object, two parameters are passed: the first parameter is the name of the constructor method ("__construct"), and the second parameter is an array of objects containing 'type', 'params', and 'stmts' properties. Multiple instances of the Node\Stmt\Expression class are added to the 'stmts' property (an array type) to initialize multiple different property variables, allowing expressions to be added to the __construct constructor. Specifically, when creating an instance object based on the Node\Stmt\Expression class, one parameter is passed: an instance object based on the Node\Expr\Assign class. When creating an instance object based on the Node\Expr\Assign class, two parameters are passed: the first parameter is an instance object based on the Node\Expr\PropertyFetch class, and the second parameter is an instance object based on the Node\Expr\New_ class. When creating an instance of the Node\Expr\PropertyFetch class, two parameters are passed: the first is the instance of the Node\Expr\Variable class (passed a string with the value "this" during creation), and the second is the name of the property variable (the name varies depending on the CRUD state), representing the specified property variable of the current API initial code class instance object under different CRUD states. When creating an instance of the Node\Expr\New_ class, two parameters are passed: the first is the instance of the Node\Name\FullyQualified class (passed a string during creation, specifying the class name of the current property variable initial value under different CRUD states as the class name of the specified target code), and the second is multiple parameters passed when creating the instance of the target code class (array type, optional, indicating no parameters are passed).

[0074] The target processing system can also create instances of the Node\Stmt\Use_ class. When creating this object, an array attribute parameter is passed in (specifying several use items), and each element (corresponding one-to-one with CRUD operations) is an instance of the Node\Stmt\UseUse class (corresponding to the class name of the target code used above, indicating the class of the imported target code). When creating an instance of the Node\Stmt\UseUse class, a parameter is passed in, which is an instance of the Node\Name\FullyQualified class (a string is passed in during creation, specifying the namespace of the imported target code class and appending the class name).

[0075] Finally, in the parsed AST tree, an instance of the Node\Stmt\ClassMethod class is added to the stmts property (array type) of the instance object based on the Node\Stmt\Class_ class. (That is, a __construct constructor is added to the initial code class of the API interface, in which the initial values ​​of different attribute variables under different CRUD states are specified as the instance objects of the corresponding target code classes.) Then, an instance of the Node\Stmt\Use_ class is added to the stmts property (array type) of the Node\Stmt\Namespace_ class. (That is, the class of the target code is introduced by adding the use content to the initial code class of the API interface.) The modified AST tree is then converted back to PHP code to generate the API interface code, thereby enabling the API interface code class to introduce the specified target code into the corresponding attribute variables under different CRUD states.

[0076] It should be noted that the above process effectively acquires information from the target data model, thereby improving the effectiveness of the generated target code. Specifically, the parsing of the data model during the initial compilation and packaging of the API interface code is relatively time-consuming (averaging only 15ms per data model), thus avoiding performance issues such as long compilation and packaging times.

[0077] In one optional embodiment, the target data model includes multiple scopes, determined based on the nesting relationships between multiple fields. The target data model also includes the basic type and attribute information of each field. During the parsing of the target data model to obtain the matching field path and field description information for each field, the target processing system can, for the first target scope within the multi-level scope, determine the field path of the fields in the first target scope based on the path of the first target scope and the field identifier of the fields in the first target scope. Then, for the fields in the first target scope, it determines the basic type and attribute information of the fields from the first target scope, and determines the field description information based on the basic type and attribute information. Next, it determines whether the field nests other fields. If a field nests other fields, it determines that the other fields belong to the first scope, and determines the field path and field description information of the other fields from the first scope. This process is repeated until it is determined that the other fields do not nest other fields. Here, "other fields" refers to fields other than the target scope, and the first scope is a scope within the multi-level scope that differs from the first target scope.

[0078] Optionally, the first target scope can refer to the outermost scope in a multi-level scope of the target data model, or it can refer to the first scope containing a field in that multi-level scope. The first target scope can contain multiple fields. After entering the first target scope, the target processing system can obtain the path $path of the first target scope and the field identifier $name of a certain field in the first target scope, thus obtaining the field path of that field as "$newPath="{$path} / {$name}"". The target processing system can also pass in the type of the first target scope after entering it; for example, the type of the first target scope can be array.

[0079] Optionally, for a field in the first target scope, the target processing system can first obtain the basic type of the field. If the basic type of the field is string, int, bool, or array, then the attribute information of the field is obtained from "#[OA\Property]". If the basic type of the field is an object type, then the attribute information of the field is obtained from both "#[OA\Property]" and "#[OA\Schema]", thus forming the field description information from the basic type and attribute information.

[0080] If the basic type of a field is an object type, the target processing system can read the class corresponding to that object type through the ReflectionClass, obtain an instance of the ReflectionClass, and retrieve the sub-attribute information in "#[OA\Schema]".

[0081] If the basic type of the field is array, then based on the attribute information of the field obtained from "#[OA\Property]", the basic type of the elements in the array is determined according to "items" in "#[OA\Property]". If the basic type of the element is array, it is determined that the element also has an "items" sub-attribute, and the "items" sub-attribute of the element is also determined as the attribute information of the field. This process continues until the last element is not of type array. If the basic type of the final element is an object type, the class corresponding to the object type is read through the ReflectionClass, an instance of the ReflectionClass is obtained, and the sub-attribute information in "#[OA\Schema]" is obtained. Thus, the sub-attribute information in "#[OA\Schema]" of the element is also determined as the attribute information of the field.

[0082] Optionally, in determining whether a field is nested with other fields, the target processing system can use the basic type to determine whether a field is nested with other fields. For example, if the basic type of the field is string, int, or bool, it is determined that the field is not nested with other fields. If the basic type of the field is an object, it is determined that the field is nested with other fields. If the basic type of the field is array, it is determined whether there are elements of type object under the field. If there are elements of type object under the field, it is determined that the field is nested with other fields; if there are no elements of type object under the field, it is determined that the field is not nested with other fields. Here, "elements under a field" can refer to elements directly contained in the field or child elements contained in elements under the field.

[0083] Optionally, when a field is nested within other fields, the target processing system determines that the nested field (i.e., other fields) belongs to the first scope, and thus determines the field path and field description information of the nested field within the first scope to which the nested field belongs. For example, the target processing system can identify the field of the object type directly to which the nested field belongs as the target field, and then iterate through all fields inside the target field (including all fields inside inherited classes, which is equivalent to iterating through the nested field) using an instance object of the ReflectionClass class. During the iteration, the system determines the basic type and the attribute information "#[OA\Property]" of the nested field within the first scope to which the nested field belongs, and determines the field path of the nested field, thereby determining the field path and field description information of the nested field. Optionally, if a field is not nested within other fields, the target processing system does not continue processing under that field.

[0084] Furthermore, the target processing system can determine whether the nested field contains other nested fields. If so, it continues to determine the field path and description information of the nested fields according to the above process until the nested field is identified as the lowest-level field. It is important to emphasize that the first scope determined each time during the iteration process is different; that is, the first scope determined each time is the scope in the multi-level scope other than the first target scope and the previously determined first scope.

[0085] It should be noted that the above process can effectively determine the field paths and field descriptions of all fields in the target data model, thereby improving the effectiveness of the generated target code.

[0086] In one optional embodiment, during the process of establishing the index relationship between a field's field path and its field description information, the target processing system can determine whether the field description information contains target attribute information. If the field description information contains target attribute information, the information in the field description information excluding the target attribute information is identified as the target field description information. If the field description information does not contain target attribute information, the field description information is identified as the target field description information, and an index relationship is established between the field's field path and the target field description information, resulting in a first index relationship. If the field description information contains target attribute information, an index relationship is established between the field's field path and the field path in the target attribute information, resulting in a second index relationship. The first and second index relationships constitute the overall index relationship. The target attribute information is used to indicate the field path transformation and includes the transformed field path.

[0087] The target attribute information is the aforementioned "correspondingKey" identifier and its corresponding value. Since the field path during processing is not unique when a field has a "correspondingKey" attribute, in order to accurately index the relevant information of the field (the field's value or its attributes other than the target attribute information) based on the field path, in this embodiment, if the field has target attribute information, a separate index relationship is established between the target attribute information and the field path.

[0088] Optionally, for each field, determine whether the field description information contains target attribute information. If it does, determine the information in the field description information other than the target attribute information as the target field description information. If it does not contain the target attribute information, determine the field description information directly as the target field description information.

[0089] After determining the target field description information, the target processing system can establish an index relationship between the field path and the target field description information, obtaining the first index relationship. If the field description information contains target attribute information, then an index relationship is established between the field path determined according to the nesting relationship between fields in the target data model and the field path in the target attribute information, obtaining the second index relationship.

[0090] It should be noted that by establishing an index relationship between the field path and the field path in the target attribute information separately when the field description information includes the target attribute information, the indexing of relevant information of the field based on the wrong field path is avoided when the field path is transformed, which would lead to indexing failure. This makes it easier to improve the effectiveness of the target code and thus improve the accuracy of data processing.

[0091] In one optional embodiment, the metadata group includes a first metadata group, a second metadata group, and a third metadata group. The second index relationship includes a first sub-index relationship for indexing field paths in target attribute information based on field paths, and a second sub-index relationship for indexing field paths in target attribute information based on field paths. During the generation of the metadata group based on the field paths, field description information, and index relationships of all fields, the target processing system can generate the first metadata group based on the field paths of all fields, the target field description information of all fields, and the first index relationship of all fields; generate the second metadata group based on the field paths of fields with target attribute information, the target attribute information, and the first sub-index relationship; and generate the third metadata group based on the field paths of fields with target attribute information, the target attribute information, and the second sub-index relationship. The data in the second metadata group is used by the API interface code to process the first data, which refers to data sent from the first end to the second end (the first end being the client and the second end being the server running the API interface code). The data in the third metadata group is used by the API interface code to process the second data, which refers to data to be sent from the second end to the first end.

[0092] The first metadata group is used for the target field description information of the field based on the field path index of the API interface code. The data in the second metadata group is used for the field path in the target attribute information based on the field path index when the API interface code processes the first data. The data in the third metadata group is used for the field path of the field based on the field path index in the target attribute information when the API interface code processes the second data.

[0093] Optionally, the target processing system can create an initial first metadata group, an initial second metadata group, and an initial third metadata group, which can be empty. The aforementioned server can be the target processing system or other servers.

[0094] The target processing system can import the field paths of all fields, the target field description information of all fields, and the first index relationship of all fields into the initial first metadata group according to preset format requirements, thereby obtaining the first metadata group. For example, an optional format for the first index relationship in the first metadata group can be "[$newPath]=['type'=>$type,'data'=>$propertyData]", where [$newPath] represents the field path, "'type'" represents the basic type in the target field description information, and "'data'" represents all sub-attribute information in the target field description information.

[0095] The target processing system can import the field paths of fields containing target attribute information, the target attribute information, and the first sub-index relationship into the initial second metadata group according to preset format requirements, thereby obtaining the second metadata group. The field paths in the target attribute information may be absolute paths or relative paths. When the field path is an absolute path, an optional format for the first sub-index relationship in the second metadata group can be "[$newPath]=$correspondingKey". When the field path is a relative path, additional code to convert the field paths in the target attribute information to absolute paths can be imported into the second metadata group.

[0096] The target processing system can generate a third metadata group from the field path of the field containing target attribute information, the target attribute information, and the second sub-index relationship. The field path in the target attribute information can be either an absolute path or a relative path. If the field path is an absolute path, an optional format for the second sub-index relationship in the third metadata group can be "[$correspondingKey]=$newPath". If the field path is a relative path, additional code to convert the field path in the target attribute information to an absolute path can be imported into the third metadata group.

[0097] It should be noted that by generating different metadata groups based on the first, second, and third sub-index relationships, it is easier to accurately determine the required data based on the data type when processing the first and second data. This allows for indexing the relevant information of the field based on the correct field path, thereby improving the effectiveness of the target code.

[0098] In an optional embodiment, after determining the API interface code based on the API interface initial code and the target code, the target processing system can construct the API interface based on the API interface code. The target code includes a first code generated based on a first metadata group and a second code generated based on a second metadata group. When the API interface receives the first data, it processes the fields in the first data according to the first code. If there is an index relationship in the second code that matches the fields in the processed first data, the field path is transformed according to the matching index relationship to obtain the transformed first data. The transformed first data is used by the API interface initial code to execute the target function.

[0099] The target code includes first code generated based on the first metadata group, second code generated based on the second metadata group, and third code generated based on the third metadata group. The API interface can be built in the aforementioned server. Figure 3 This is a schematic diagram of an optional API interface for processing first data according to an embodiment of the present invention. Figure 1 ,like Figure 3 As shown, after constructing the API interface, if the API interface receives the first data, it can first process the fields in the first data according to the first code. Then, it determines whether there is an index relationship in the second code that matches the fields in the processed first data. If there is, it determines that the fields in the first data need to be converted, and converts the field paths in the processed first data into field paths in the target attribute information according to the matching index relationship, obtaining the converted first data. The converted first data can be passed to the underlying layer (such as a database) so that the API interface initial code can execute the target function, which can refer to a business function. If there is no index relationship in the second code that matches the fields in the processed first data, the target processing system can directly pass the processed first data to the underlying layer so that the API interface initial code can execute the target function.

[0100] Optional, such as Figure 3 As shown, if an exception occurs (such as a validation error) during the processing of fields in the first data according to the first code, the subsequent steps will be stopped.

[0101] It's important to note that since the field paths in the data sent by the client may differ from the field paths required by the underlying logic, processing the fields in the first data via the API interface's initial code ensures that the API interface's initial code can effectively retrieve all fields from the first data to execute the target function. This avoids indexing failures caused by incorrect field paths when field paths are converted. Furthermore, by building the API interface based on the API interface code, the API interface does not require any tools at runtime; that is, it does not need to use dependency management tools (like Composer) to import any libraries. Therefore, its space consumption is smaller (not exceeding 1MB, while using Composer with libraries easily exceeds 10MB), reducing resource consumption and making it suitable for developing high-performance micro-applications.

[0102] In one alternative embodiment, Figure 4 This is a schematic diagram of the operation of an optional API interface according to an embodiment of the present invention. Figure 2 ,like Figure 4As shown, when the API interface receives the second data, if the third code contains an index relationship that matches a field in the second data, it performs field path transformation on the fields in the second data based on the matching index relationship to obtain the transformed second data. Then, it processes the transformed second data according to the first code to obtain the processed second data. The processed second data is then sent to the first end. Optionally, if the third code does not contain an index relationship that matches a field in the second data, it directly processes the second data according to the first code to obtain the processed second data.

[0103] In the process of converting the field paths of the fields in the second data, the field paths of the fields in the second data can be converted from the field paths in the target attribute information to the field paths used in the first code based on the matching index relationship, thereby obtaining the converted first data.

[0104] It should be noted that since the field paths required for the fields in the data to be sent to the client may be different from the field paths used when the underlying logic processes the fields, the client can effectively obtain each field in the second data by processing the fields in the second data based on the first and third codes during the API interface processing of the second data.

[0105] In one optional embodiment, during the process of the API interface processing fields in the first data according to the first code, for the second target scope in the first data, the API interface determines the actual field path of the field in the second target scope according to the second target scope. If the target field description information is indexed from the first code according to the actual field path, the API interface processes the field according to the indexed target field description information. If the processing result indicates that the field does not have any abnormalities, the API interface determines whether the field is nested with other fields. If the field is nested with other fields, the API interface determines that the other fields belong to the second scope. The API interface repeats the step of determining the actual field path of other fields according to the second scope until the processing result indicates that the field has any abnormalities or it is determined that the other fields are not nested with other fields. The second scope is a scope in the first data that is different from the second target scope.

[0106] The second target scope can refer to the outermost scope in the multi-level scope of the first data, or it can refer to the first scope containing a field in the multi-level scope of the first data. The second target scope can contain multiple fields.

[0107] For example, Figure 5 This is a schematic diagram of an optional API interface for processing first data according to an embodiment of the present invention. Figure 2 ,like Figure 5As shown, for the second target scope in the first data, the API interface can determine the actual field path of the field in the second target scope based on the second target scope and obtain the value of that field. For example, the actual field path of the field in the second target scope can be determined based on the path of the second target scope and the field identifier of the field in the second target scope. Then, indexing is performed in the first code based on the actual field path. If the target field description information is indexed from the first code based on the actual field path, the field is processed (e.g., validation, conversion, etc.) based on the field value and the indexed target field description information. For example, assuming the basic type of the "name" field in the first data is string and its value is "aaa", the target field description information of the "name" field in the first code is used to validate the field as a string type, and the minLength value and maxLength value in the target field description information are 4 and 6 respectively, then validation is performed and it is determined that the validation failed. As another example, assuming the basic type of the "name" field in the first data is string and its value is "aaaaa", then validation is performed and it is determined that the validation passed. During processing, if the target field description is of type string, int, bool, etc., and contains an "enum" sub-attribute (i.e., there is a constraint on the enumerated value), the API interface can first determine whether the field value falls within the range of values ​​defined by the "enum" sub-attribute, and then perform other processing, such as performing validation and conversion related to "type" and "format". Figure 5 As shown, if the field in the target field description information is of type array, then each element in the field is traversed, and each element is processed according to the content of the target field description information. It is important to emphasize that when processing the elements in the field, since the field path of the element is the same as the field path of the field, and the attribute of the element is defined in the target field description information of the field, the elements under the field are processed according to the target field description information. For example, the elements under the field are processed according to the information in "items" in the target field description information.

[0108] After processing, such as Figure 5 As shown, if the field is of type string, int, bool, etc., it is determined that the field is not nested with other fields, and processing of that field is considered complete. If the field is of type array, it is checked whether there are elements of type object. If there are elements of type object, it is determined that the field is nested with other fields; if there are no elements of type object, it is determined that the field is not nested with other fields. If the field is of type object, it is determined that the field is nested with other fields.

[0109] Optional, such as Figure 5 As shown, when a field is nested within another field, the API interface determines that the nested field (i.e., the other field) belongs to the second scope. Within this second scope, it determines the actual field path and value of the nested field to complete the traversal of the nested field. Then, the API interface indexes the first code based on the actual field path of the nested field. If the target field description information is found, the API interface processes the nested field based on its value and the indexed target field description information. Afterward, the API interface can determine if the nested field contains other nested fields. If so, it continues to determine the actual field path and value of the nested fields according to the above process until the nested field is identified as the lowest-level field. It is important to emphasize that the second scope determined each time during the iteration is different; that is, the second scope determined each time is the scope in the first data other than the second target scope and the previously determined second scope.

[0110] Optionally, for fields of basic type array or object type, when the field's format (format in "#[OA\Property]" or format in "#[OA\Schema]") contains a target validation transformation method, this target validation transformation method is processed after traversing the data within the field (elements under the field or fields nested under the field). The target validation transformation method can be determined based on its identifier. The target validation transformation method can be a custom validation transformation method, such as validation transformation methods other than those for ipv4, netmask, prefix-length, domain, and password mentioned above. This avoids the possibility of false errors when processing the data within the field if the target validation transformation method processes the data within the field first, thus improving the accuracy of data processing.

[0111] Among them, such as Figure 5 As shown, if the target field description information cannot be indexed from the first code based on the actual field path, or if an exception occurs during the processing of the field based on the target field description information, the API interface will directly report an error and stop subsequent steps. The aforementioned exceptions may include field validation failure, field conversion failure, or the field value not existing in the specified enumeration values.

[0112] It should be noted that the above process can effectively process all fields in the first set of data, thereby improving the reliability and accuracy of data processing.

[0113] In an optional embodiment, during the process of the API interface processing fields in the second data according to the first code, for the third target scope in the second data, the API interface determines the actual field path of the field in the third target scope based on the third target scope, and indexes the target field description information from the first code based on the actual field path. Then, the API interface processes the field based on the indexed target field description information and determines whether the field is nested with other fields. If the field is nested with other fields, the API interface determines that the other fields belong to the third scope and repeats the step of determining the actual field path of other fields based on the third scope until the processing result indicates that the field is abnormal or that other fields are not nested with fields other than other fields. The third scope is a scope in the multi-level scope that is different from the third target scope.

[0114] The third target scope can refer to the outermost scope in the multi-level scope of the second data, or it can refer to the first scope containing a field in the multi-level scope of the second data. The third target scope can contain multiple fields.

[0115] For example, Figure 6 This is a schematic diagram of an optional API interface for processing second data according to an embodiment of the present invention. Figure 2 ,like Figure 6 As shown, for the third target scope in the second data, the API interface can determine the actual field path of the field in the third target scope and obtain the value of that field. For example, the actual field path of the field in the third target scope can be determined based on the path of the third target scope and the field identifier of the field in the third target scope. Then, the target field description information is indexed from the first code based on the actual field path, and the field is processed based on the field value and the indexed target field description information. During processing, if the field in the target field description information is of object type, each element in the field is traversed, and each element is processed according to the content of the target field description information.

[0116] After processing, such as Figure 6 As shown, if the field is of type string, int, bool, etc., it is determined that the field is not nested with other fields, and processing of that field is considered complete. If the field is of type array, it is checked whether there are elements of type object. If there are elements of type object, it is determined that the field is nested with other fields; if there are no elements of type object, it is determined that the field is not nested with other fields. If the field is of type object, it is determined that the field is nested with other fields.

[0117] Optional, such as Figure 6As shown, when a field is nested within another field, the API interface determines that the nested field (i.e., the other field) belongs to a third scope. Within this third scope, it then determines the actual field path and value of the nested field to complete the traversal of the nested field. Next, based on the actual field path of the nested field, the API interface indexes the target field description information from the first code. It then processes the nested field according to its value and the indexed target field description information. Afterward, the API interface can determine if the nested field contains other nested fields. If so, it continues to determine the actual field path and value of the nested fields according to the above process until the nested field is identified as the lowest-level field.

[0118] Since the second data is to be sent from the second end to the first end, the target field description information can always be indexed from the first code based on the actual field paths in the second data. Furthermore, when processing fields based on the target field description information, no data validation is required, meaning no anomalies will occur. It is important to emphasize that the determined third scope is different each time during the iteration process; that is, the determined third scope each time refers to all scopes in the second data other than the third target scope and the previously determined third scope.

[0119] It should be noted that the above process can effectively process all fields in the second set of data, thereby improving the reliability and accuracy of data processing.

[0120] In one alternative embodiment, Figure 7 This is a schematic diagram illustrating an optional processing method for the target API interface code according to an embodiment of the present invention, such as... Figure 7 As shown, when the target processing system runs a specific target API interface code, it can detect whether the specified variables (such as class attributes) in the target API interface code have been assigned values ​​of the parsed metadata of the data model. If values ​​have been assigned, it determines that the data model specified by the target API interface code has been parsed and can be directly run to process data. Conversely, if no values ​​have been assigned, it determines that the data model specified by the target API interface code has not been parsed. In this case, the data model is parsed to obtain the fields supported at each different level, the field types, validation and conversion methods, etc., forming a metadata group. This metadata group is then assigned to the specified variables in the target API interface code, and the data is processed according to the assigned target API interface code. The target API interface code can refer to the API interface code that the target processing system runs for the first time.

[0121] It should be noted that the above process enables effective data processing based on the API interface code even when the target code is not present in the API interface code.

[0122] In one alternative embodiment, after obtaining the target data model that matches the initial code of the API interface from a plurality of preset data models, the target processing system can generate API documentation corresponding to the API interface code based on the target data model.

[0123] Optionally, the target processing system can generate JSON or YAML files based on the OpenAPI specification according to the target data model, and then generate API documentation corresponding to the API interface code based on the generated files. The API documentation is used to describe each field of the data. Figure 8 This is a schematic diagram of an optional API documentation generation method according to an embodiment of the present invention, such as... Figure 8 As shown, when there are multiple API interface codes, the target processing system can traverse the target data model corresponding to each API interface code. During the traversal, for each target data model, the system parses the target data model to generate JSON or YAML data based on the OpenAPI specification. After the traversal is completed, the system generates JSON or YAML files based on the JSON or YAML data corresponding to all target data models, and then generates API documentation based on the JSON or YAML files.

[0124] It's important to note that in related technologies, API interface code and API documentation often require writing two separate sets of code, making maintenance difficult. Furthermore, the data descriptions in the API documentation and the data structures in the actual API interface code are hard to keep consistent. Additionally, the logic for filtering, validating, and transforming each field in the API interface code is complex, scattered across various business processes, and lacks unified control. In this embodiment, however, by generating API documentation based on the target data model, both API interface code development and API documentation generation are achieved using the same data content, reducing human resource consumption. Moreover, the API documentation directly reflects the functionality implemented by the API interface code, with no discrepancies. Furthermore, it effectively improves the standardization, uniformity, and internal data coupling of the API interface code, facilitating code maintenance.

[0125] In one optional embodiment, during the process of generating API documentation corresponding to the API interface code based on the target data model, the target processing system can define annotations in the initial API interface code and reference the target data model in the annotations. Then, an API documentation generation tool reads the target data model referenced in the annotations and generates a target file based on the target data model. The API documentation generation tool then performs visualization processing on the data in the target file to obtain the API documentation. Here, the target file is a file in the target format, and the annotations are used by the API documentation generation tool to read the content within the annotations.

[0126] Optionally, the target processing system can define annotations on different methods in the initial code of the API interface, and reference the target data model corresponding to the method in the requestBody and responses of the annotations. That is, the initial code of the API interface may reference multiple target data models. Here, requestBody is used to describe the request body parameters received by the API endpoint, and responses are used to describe the response body parameters of the API endpoint.

[0127] Next, the target processing system can use the API documentation generation tool to read all target data models referenced by the annotations and generate target files based on all target data models. These target files are JSON or YAML files based on the OpenAPI specification. Then, the API documentation generation tool performs visualization processing on the data in the target files to obtain the API documentation.

[0128] It should be noted that the above process enables the effective generation of API documentation.

[0129] Therefore, the solution provided in this application achieves the goal of generating target code based on the data model and generating API interface code based on the target code, thereby reducing the impact on system performance. It also solves the technical problem in related technologies where API interface code needs to parse the data model to process interactive data during runtime, thus affecting system performance.

[0130] Example 2

[0131] According to an embodiment of the present invention, an embodiment of an API interface code processing apparatus is provided, wherein, Figure 9 This is a schematic diagram of an optional API interface code processing device according to an embodiment of the present invention, such as... Figure 9 As shown, the device includes:

[0132] The first acquisition module 901 is used to acquire the initial code of the API interface, wherein the initial code of the API interface is the functional code required by the API interface code to be generated;

[0133] The second acquisition module 902 is used to acquire the target data model matching the initial code of the API interface from a plurality of preset data models. The target data model includes information on the processing method for the target data structure, and the target data structure is the data structure of the data interacted by the API interface code to be generated.

[0134] The first generation module 903 is used to generate target code based on the target data model, wherein the target code is used to process the target data structure;

[0135] Processing module 904 is used to determine the API interface code based on the API interface initial code and target code.

[0136] It should be noted that the first acquisition module 901, the second acquisition module 902, the first generation module 903 and the processing module 904 mentioned above correspond to steps S101 to S104 in the above embodiments. The examples and application scenarios implemented by the four modules and the corresponding steps are the same, but are not limited to the content disclosed in the above embodiment 1.

[0137] Optionally, the target data structure includes the data structure of multiple fields in the data. The first generation module further includes: a first processing submodule, used to parse the target data model to obtain the field path and field description information matching each field, wherein the field description information includes at least the basic type and attribute information of the field, and the attribute information is used to characterize the processing method of the field's data structure; a second processing submodule, used to establish an index relationship between the field path and the field description information for each field; a first generation submodule, used to generate a metadata group based on the field paths, field description information, and index relationships of all fields; and a second generation submodule, used to generate target code based on the metadata group.

[0138] Optionally, the target data model contains multiple scopes, which are determined based on the nesting relationships between multiple fields. The first processing submodule further includes: a first determining unit, used to determine the field path of a field in the first target scope based on the path of the first target scope and the field identifier of the field in the first target scope; a second determining unit, used to determine the basic type and attribute information of a field in the first target scope, and determine the field description information of the field based on the basic type and attribute information; a first judging unit, used to judge whether a field nests other fields, where other fields refer to fields other than the first target scope; a third determining unit, used to determine that other fields belong to the first scope when a field nests other fields, and determine the field path and field description information of other fields from the first scope, where the first scope is a scope in the multi-level scope that is different from the first target scope; and a first processing unit, used to repeatedly execute the step of judging whether other fields nest other fields until it is determined that other fields do not nest other fields.

[0139] Optionally, the second processing submodule further includes: a second judgment unit, used to judge whether the field description information contains target attribute information, wherein the target attribute information is used to indicate field path conversion of the field, and the target attribute information includes the converted field path; a fourth determination unit, used to determine the information other than the target attribute information in the field description information as the target field description information when the field description information contains target attribute information; a fifth determination unit, used to determine the field description information as the target field description information when the field description information does not contain target attribute information; and a second processing unit, used to establish an index relationship between the field path of the field and the target field description information to obtain a first index relationship, and, when the field description information contains target attribute information, establish an index relationship between the field path of the field and the field path in the target attribute information to obtain a second index relationship, wherein the first index relationship and the second index relationship constitute an index relationship.

[0140] Optionally, the metadata group includes a first metadata group, a second metadata group, and a third metadata group. The second index relationship includes a first sub-index relationship for indexing field paths in target attribute information based on field paths, and a second sub-index relationship for indexing field paths in target attribute information based on field paths. The first generation submodule further includes: a first generation unit for generating the first metadata group based on the field paths of all fields, the target field description information of all fields, and the first index relationship of all fields; a second generation unit for generating the second metadata group based on the field paths of fields with target attribute information, the target attribute information, and the first sub-index relationship, wherein the data in the second metadata group is used by the API interface code to process the first data, which refers to data sent from the first end to the second end (the first end being the client, and the second end being the server running the API interface code); and a third generation unit for generating the third metadata group based on the field paths of fields with target attribute information, the target attribute information, and the second sub-index relationship, wherein the data in the third metadata group is used by the API interface code to process the second data, which refers to data to be sent from the second end to the first end.

[0141] Optionally, the API interface code processing device further includes: a construction module for constructing an API interface based on the API interface code, wherein the target code includes first code generated according to a first metadata group and second code generated according to a second metadata group. When the API interface receives first data, it processes the fields in the first data according to the first code. If there is an index relationship in the second code that matches the fields in the processed first data, then the fields in the processed first data are converted according to the matching index relationship to obtain the converted first data. The converted first data is used for the API interface initial code to execute the target function.

[0142] Optionally, during the process of processing fields in the first data according to the first code, the API interface determines the actual field path of the field in the second target scope based on the second target scope. If the target field description information is indexed from the first code based on the actual field path, the field is processed based on the indexed target field description information. If the processing result indicates that the field does not have any anomalies, it is determined whether the field is nested with other fields. If the field is nested with other fields, it is determined that the other fields belong to the second scope, and the step of determining the actual field path of other fields based on the second scope is repeated until the processing result indicates that the field has any anomalies or other fields are not nested with fields other than other fields. Here, the second scope is a scope in the first data that is different from the second target scope.

[0143] Optionally, the API interface code processing device further includes: a second generation module, used to generate API documentation corresponding to the API interface code based on the target data model.

[0144] Optionally, the second generation module further includes: a third processing submodule, used to define annotations in the initial code of the API interface and reference the target data model in the annotations, wherein the annotations are used by the API documentation generation tool to read the content in the annotations; a third generation submodule, used to use the API documentation generation tool to read the target data model referenced by the annotations and generate a target file based on the target data model, wherein the target file is a file in the target format; and a fourth processing submodule, used to perform visualization processing on the data in the target file through the API documentation generation tool to obtain the API documentation.

[0145] Example 3

[0146] According to another aspect of the present invention, a computer-readable storage medium is also provided, wherein a computer program is stored in the computer-readable storage medium, and the computer program is configured to execute the processing method of the above-described API interface code at runtime.

[0147] Example 4

[0148] According to another aspect of the present invention, an electronic device is also provided, wherein, Figure 10 This is a schematic diagram of an optional electronic device according to an embodiment of the present invention, such as... Figure 10 As shown, the electronic device includes one or more processors; and a memory for storing one or more programs, which, when executed by one or more processors, cause the one or more processors to implement a processing method for running the program, wherein the program is configured to execute the aforementioned API interface code during runtime.

[0149] The sequence numbers of the above embodiments of the present invention are for descriptive purposes only and do not represent the superiority or inferiority of the embodiments.

[0150] In the above embodiments of the present invention, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0151] In the several embodiments provided in this application, it should be understood that the disclosed technical content can be implemented in other ways. The device embodiments described above are merely illustrative; for example, the division of units can be a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the displayed or discussed mutual couplings, direct couplings, or communication connections may be through some interfaces; indirect couplings or communication connections between units or modules may be electrical or other forms.

[0152] 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 units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0153] Furthermore, the functional units in the various embodiments of the present invention can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0154] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present invention, in essence, or the part that contributes to the prior art, or all or part 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 of the various embodiments of the present invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, read-only memory (ROM), random access memory (RAM), portable hard drives, magnetic disks, or optical disks.

[0155] The above are merely preferred embodiments of the present invention. It should be noted that those skilled in the art can make various improvements and modifications without departing from the principle of the present invention, and these improvements and modifications should also be considered within the scope of protection of the present invention.

Claims

1. A method for processing API interface code, characterized in that, include: Obtain the initial code of the API interface, wherein the initial code of the API interface is the functional code required for the API interface code to be generated; Obtain the target data model matching the initial code of the API interface from a set of preset data models. The target data model includes information on the processing method for the target data structure. The target data structure is the data structure of the data interacted by the API interface code to be generated. Target code is generated based on the target data model, wherein the target code is used to process the target data structure; The API interface code is determined based on the initial API interface code and the target code. The target data structure includes the data structure of multiple fields in the data, wherein generating target code based on the target data model includes: The target data model is parsed to obtain the field path and field description information matching each field. The field description information includes at least the basic type and attribute information of the field, and the attribute information is used to characterize the processing method of the data structure of the field. For each field, establish an index relationship between the field path and the field description information of the field; Generate metadata groups based on the field paths, field descriptions, and index relationships of all fields; The target code is generated based on the metadata group; Establishing an index relationship between the field path and the field description information of the field includes: Determine whether the field description information contains target attribute information, wherein the target attribute information is used to indicate field path conversion for the field, and the target attribute information includes the converted field path; If the target attribute information is included in the field description information, the information in the field description information other than the target attribute information shall be determined as the target field description information; If the target attribute information is not included in the field description information, the field description information is determined as the target field description information; An index relationship is established between the field path of the field and the target field description information to obtain a first index relationship. If the target attribute information is included in the field description information, an index relationship is established between the field path of the field and the field path in the target attribute information to obtain a second index relationship. The first index relationship and the second index relationship constitute the index relationship.

2. The method according to claim 1, characterized in that, The target data model contains multiple scopes, which are determined based on the nesting relationships between the multiple fields. Parsing the target data model yields the field path and field description information for each field, including: For the first target scope in the multi-level scope, the field path of the field in the first target scope is determined according to the path of the first target scope and the field identifier of the field in the first target scope. For a field in the first target scope, determine the basic type and attribute information of the field from the first target scope, and determine the field description information of the field based on the basic type and attribute information of the field; Determine whether the field is nested with other fields, where other fields refer to fields other than the field itself; When the field is nested with other fields, it is determined that the other fields belong to a first scope, and the field path and field description information of the other fields are determined from the first scope, wherein the first scope is a scope in the multi-level scope that is different from the first target scope; Repeat the step of determining whether the other fields are nested with fields other than the other fields, until it is determined that the other fields are not nested with fields other than the other fields.

3. The method according to claim 1, characterized in that, The metadata group includes a first metadata group, a second metadata group, and a third metadata group. The second index relationship includes a first sub-index relationship for indexing field paths in the target attribute information based on the field paths of the field, and a second sub-index relationship for indexing field paths of the field based on the field paths in the target attribute information. The metadata group is generated based on the field paths, field description information, and index relationships of all fields, including: The first metadata group is generated based on the field paths of all fields, the target field description information of all fields, and the first index relationship of all fields; The second metadata group is generated based on the field path of the field with target attribute information, the target attribute information, and the first sub-index relationship. The data in the second metadata group is used by the API interface code to process the first data. The first data refers to the data sent from the first end to the second end. The first end is the client, and the second end is the server running the API interface code. The third metadata group is generated based on the field path of the field with target attribute information, the target attribute information, and the second sub-index relationship. The data in the third metadata group is used by the API interface code to process the second data, which refers to the data to be sent from the second end to the first end.

4. The method according to claim 3, characterized in that, After determining the API interface code based on the API interface initial code and the target code, the method further includes: An API interface is constructed based on the API interface code. The target code includes first code generated according to the first metadata group and second code generated according to the second metadata group. When the API interface receives the first data, it processes the fields in the first data according to the first code. If there is an index relationship in the second code that matches the fields in the processed first data, the field path is transformed according to the matching index relationship to obtain the transformed first data. The transformed first data is used by the initial code of the API interface to execute the target function.

5. The method according to claim 4, characterized in that, The method further includes: In the process of processing the fields in the first data according to the first code, the API interface determines the actual field path of the field in the second target scope based on the second target scope. If the target field description information is indexed from the first code based on the real field path, the field is processed based on the indexed target field description information, and if the processing result indicates that the field does not have any abnormalities, it is determined whether the field is nested with other fields; When the field is nested with other fields, it is determined that the other fields belong to the second scope, and the step of determining the real field path of the other fields according to the second scope is repeated until the processing result indicates that the field is abnormal or it is determined that the other fields are not nested with fields other than the other fields. The second scope is the scope in the first data that is different from the second target scope.

6. The method according to any one of claims 1 to 5, characterized in that, After obtaining the target data model matching the initial code of the API interface from a plurality of preset data models, the method further includes: Generate the API documentation corresponding to the API interface code based on the target data model.

7. The method according to claim 6, characterized in that, Based on the target data model, generate the API documentation corresponding to the API interface code, including: Annotations are defined in the initial code of the API interface, and the target data model is referenced in the annotations. The annotations are used by the API documentation generation tool to read the content in the annotations. The API documentation generation tool is used to read the target data model referenced by the annotation, and a target file is generated based on the target data model, wherein the target file is a file in the target format; The API documentation is obtained by visualizing the data in the target file using the API documentation generation tool.

8. An API interface code processing device, characterized in that, For performing the method according to any one of claims 1 to 7, comprising: The first acquisition module is used to acquire the initial code of the API interface, wherein the initial code of the API interface is the functional code required by the API interface code to be generated; The second acquisition module is used to acquire the target data model matching the initial code of the API interface from a plurality of preset data models, wherein the target data model includes information on the processing method for the target data structure, and the target data structure is the data structure of the data interacted by the API interface code to be generated; The first generation module is used to generate target code based on the target data model, wherein the target code is used to process the target data structure; The processing module is used to determine the API interface code based on the API interface initial code and the target code.

Images