Interface processing method and device, equipment and medium

Abstract

The invention provides an interface processing method and device, equipment and a medium, and belongs to the technical field of data processing. The method comprises the steps that under the condition that it is detected that a first interface code of a first interface is updated, a second interface code obtained after the first interface is updated is obtained; obtaining a code comparison result between the second interface code and the first interface code; under the condition that the code comparison result is matched with the preset rule, it is determined that the second interface code has code change information relative to the first interface code; and determining a code change type of the code change information, determining a target field corresponding to the code change type from the at least two fields, and updating a field value corresponding to the target field in the interface version number. According to the mode, the target field needing to be updated in the multiple fields can be automatically determined, so that rapid and accurate updating of the interface version number is realized.

Description

Technical Field

[0001] The present application relates to the field of data processing technology, and in particular to an interface processing method, apparatus, device, and computer-readable storage medium. Background Art

[0002] Interfaces include various types, including software interfaces and application programming interfaces (APIs). Software interfaces are a broad concept that refers to the points of interaction between different software components, between computer hardware and software, or between users and computer systems. These interfaces define the communication rules and data formats between components and can take the form of functions, methods, protocols, messages, and other methods, describing how to call or use a software component or service.

[0003] An application programming interface (API) is a specific type of software interface. It's a set of methods and tools provided by an application to developers for interacting with that application. An API defines the functions, classes, objects, protocols, and other features available to developers, along with their parameters, return values, and usage. It's typically used to access functionality within an operating system, library, framework, service, or other software component. In short, an API is a programming interface provided by an application or service, enabling developers to interact with it.

[0004] To facilitate developers' flexible call access to various interfaces, interfaces can be identified by their version numbers. These numbers are used to distinguish and process different versions of interfaces, ensuring compatibility and stability. However, in related technologies, when an interface is updated, the version number cannot be used to update it accordingly. Summary of the Invention

[0005] The present application provides an interface processing method, apparatus, device and computer-readable storage medium, which can automatically update the interface version number to match the interface after the interface is updated.

[0006] In a first aspect, the present application provides an interface processing method, which includes:

[0007] When detecting that a first interface code of a first interface is updated, obtaining a second interface code after the first interface is updated;

[0008] Comparing the second interface code with the first interface code to obtain a code comparison result;

[0009] If the code comparison result matches a preset rule, determining that code change information exists in the second interface code;

[0010] Determining a change type of the code change information according to the preset rule, and determining a field corresponding to the change type from the fields included in the interface version number of the first interface;

[0011] The corresponding field value in the interface version number of the first interface is updated according to the field corresponding to the change type.

[0012] In a second aspect, the present application provides an interface processing device, the interface processing device comprising:

[0013] a detection module, adapted to, upon detecting that a first interface code of a first interface is updated, obtain a second interface code after the first interface is updated;

[0014] a comparison module, adapted to compare the second interface code with the first interface code to obtain a code comparison result;

[0015] a matching module, adapted to determine whether code change information exists in the second interface code if the code comparison result matches a preset rule;

[0016] a determination module, adapted to determine a change type of the code change information according to the preset rule, and determine a field corresponding to the change type from the fields included in the interface version number of the first interface;

[0017] An updating module is adapted to update a corresponding field value in the interface version number of the first interface according to the field corresponding to the change type.

[0018] In a third aspect, the present application provides an electronic device comprising: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores one or more computer programs executable by the at least one processor, and one or more of the computer programs are executed by the at least one processor so that the at least one processor can execute the above-mentioned interface processing method.

[0019] In a fourth aspect, the present application provides a computer-readable storage medium having a computer program stored thereon, wherein the computer program implements the above-mentioned interface processing method when executed by a processor / processing core.

[0020] In a fifth aspect, the present disclosure provides a computer program product comprising a computer-readable code, or a non-volatile computer-readable storage medium carrying the computer-readable code. When the computer-readable code runs in a processor of an electronic device, the processor in the electronic device executes the above-mentioned interface processing method.

[0021] In the interface processing method provided by the present disclosure, when it is detected that the first interface code of the first interface has been updated, the second interface code after the first interface is updated is compared with the first interface code, and when the code comparison result matches the preset rule, it is determined that the second interface code has code change information relative to the first interface code; according to the change type of the code change information, the field corresponding to the change type is determined from the fields included in the interface version number of the first interface, and the field value of the corresponding field in the interface version number of the first interface is updated. It can be seen that the present application can determine whether the change between the interface code before and after the update is related to the version update according to the preset rules. If it is related to the version update, it means that the second interface code has code change information relative to the first interface code. Accordingly, the present application can determine the field corresponding to the change type from the fields included in the interface version number of the first interface according to the change type of the code change information, thereby realizing accurate update processing of the field. Therefore, the present application can not only determine whether the version number needs to be updated according to the change of the interface code, but also automatically determine the field that needs to be updated among multiple fields according to the change type of the interface code, thereby realizing fast and accurate update of the interface version number, thereby avoiding call failures caused by untimely update of the version number.

[0022] It should be understood that the content described in this section is not intended to identify the key or important features of the embodiments of the present application, nor is it intended to limit the scope of the present application. Other features of the present application will become easily understood through the following description. BRIEF DESCRIPTION OF THE DRAWINGS

[0023] The accompanying drawings are used to provide a further understanding of the present application and constitute a part of the specification. Together with the embodiments of the present application, they are used to explain the present application and do not constitute a limitation of the present application. The above and other features and advantages will become more apparent to those skilled in the art by describing the detailed exemplary embodiments with reference to the accompanying drawings. In the accompanying drawings:

[0024] Figure 1 A flowchart of an interface processing method provided in an embodiment of the present application;

[0025] Figure 2 A schematic diagram of an interface processing method provided for a specific example of this application;

[0026] Figure 3 A block diagram of an interface processing device provided in an embodiment of the present application;

[0027] Figure 4 A block diagram of an electronic device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0028] To help those skilled in the art better understand the technical solutions of the present application, the following description of exemplary embodiments of the present application is provided in conjunction with the accompanying drawings, including various details of the embodiments of the present application to facilitate understanding. These details should be considered merely exemplary. Therefore, those skilled in the art should recognize that various changes and modifications can be made to the embodiments described herein without departing from the scope and spirit of the present application. Similarly, for the sake of clarity and conciseness, descriptions of well-known functions and structures are omitted in the following description.

[0029] In the absence of conflict, the various embodiments of the present application and the various features therein may be combined with each other.

[0030] As used herein, the term "and / or" includes any and all combinations of one or more of the associated listed items.

[0031] The terms used herein are only used to describe specific embodiments and are not intended to limit this application. As used herein, the singular forms "a" and "the" are also intended to include the plural forms, unless the context clearly indicates otherwise. It will also be understood that when the terms "comprising" and / or "made of" are used in this specification, the presence of the features, wholes, steps, operations, elements and / or components is specified, but the presence or addition of one or more other features, wholes, steps, operations, elements, components and / or groups thereof is not excluded. Similar words such as "connected" or "connected" are not limited to physical or mechanical connections, but can include electrical connections, whether direct or indirect.

[0032] Unless otherwise defined, all terms (including technical and scientific terms) used herein have the same meaning as commonly understood by one of ordinary skill in the art. It will also be understood that terms such as those defined in commonly used dictionaries should be interpreted as having a meaning consistent with their meaning in the context of the relevant art and this application, and will not be interpreted as having an idealized or overly formal meaning unless expressly defined as such herein.

[0033] In order to facilitate developers to flexibly call various interfaces, interfaces can be identified by interface version numbers. Among them, the interface version number is used to distinguish and manage different versions of interfaces to ensure the compatibility and stability of the interface. However, in related technologies, when the interface is updated, the interface version number cannot achieve automatic update processing that is compatible with the interface. In order to solve the above problems, the present disclosure can automatically detect the change type of the updated interface code, and automatically determine the field corresponding to the change type in multiple fields of the version number, thereby realizing automatic update processing of the interface version number, thereby avoiding call failures caused by untimely updates of the version number.

[0034] The interface processing method according to the embodiment of the present application can be executed by an electronic device such as a terminal device or a server. The terminal device can be a user equipment (UE), a mobile device, a user terminal, a terminal, a cellular phone, a cordless phone, a personal digital assistant (PDA), a handheld device, a computing device, a vehicle-mounted device, a wearable device, etc. The method can be implemented by a processor calling a computer-readable program instruction stored in a memory. The server can be an independent physical server, a server cluster consisting of multiple servers, or a cloud server capable of cloud computing.

[0035] Figure 1 This is a flowchart of an interface processing method provided in an embodiment of the present application. Figure 1 , the method comprising:

[0036] Step S110: when it is detected that the first interface code of the first interface is updated, obtaining the updated second interface code of the first interface.

[0037] The first interface refers to the interface whose version number is to be monitored to determine whether it needs to be updated, which can specifically be various application program interfaces. The first interface can also be called the target interface. The first interface code refers to the interface code of the first interface corresponding to the current interface version number (i.e., the interface code before the update). Correspondingly, the second interface code refers to the interface code after the first interface is updated.

[0038] The purpose of this application is to automatically determine whether the interface version number needs to be updated, and how to update the interface version number based on the interface code of the first interface after the interface code is updated. In order to achieve the above purpose, this application can monitor whether the interface code of the first interface has changed, and if the detection result is yes, obtain the second interface code after the first interface is updated.

[0039] Whether the first interface code of the first interface is updated can be monitored by various code monitoring tools.

[0040] Step S120: Compare the second interface code with the first interface code to obtain a code comparison result.

[0041] Specifically, the comparison may be performed in various ways, for example, line-by-line comparison, function comparison, etc. Optionally, a code comparison result may be obtained between a second code analysis result corresponding to the second interface code and a first code analysis result corresponding to the first interface code.

[0042] The second code analysis result corresponding to the second interface code can be determined through various methods such as static analysis and / or dynamic analysis. In short, the second code analysis result is used to characterize the analysis of the second interface code at the code implementation logic level. Similarly, the first code analysis result corresponding to the first interface code can also be determined through various methods such as static analysis and / or dynamic analysis. The first code analysis result is used to characterize the analysis of the first interface code at the code implementation logic level.

[0043] Accordingly, the code comparison result is used to characterize the difference between the second interface code and the first interface code, which may specifically include: differences in logical structure, differences in code performance, differences in code functionality, etc. In short, this application does not limit the specific connotation of the code comparison result.

[0044] Step S130: When the code comparison result matches the preset rule, it is determined that code change information exists in the second interface code.

[0045] Among them, the preset rule (also known as the preset code change rule) can be one or more, and specifically, multiple preset rules can be uniformly stored through a preset rule library. Each preset rule is used to characterize a type of code change that requires updating the interface version number. Since in actual situations, not all situations that can produce code changes require updating the interface version number, therefore, in this application, at least one preset rule is pre-set to record code changes that require updating the interface version number. Accordingly, when the code comparison result matches the preset rule, it is determined that the second interface code has code change information relative to the first interface code. Among them, code change information refers to: the code change part that requires updating the interface version number.

[0046] As can be seen, in this step, the code comparison result needs to be matched with the preset rules. If the match fails, it means that there is no code change information for the second interface code relative to the first interface code. The absence of code change information does not mean that the second interface code has not changed relative to the first interface code, but rather that the change in the second interface code relative to the first interface code is not sufficient to cause an update of the interface version number.

[0047] Step S140: Determine the change type of the code change information according to a preset rule, and determine the field corresponding to the change type from the fields included in the interface version number of the first interface. The change type of the code change information (also called the code change type) is used to characterize specific characteristics such as the type of change, change dimension, change amplitude and / or change level of the code change information. In addition, there is a preset correspondence between the multiple change types of the code change information and the multiple fields included in the interface version number. Accordingly, according to the change type of the code change information, the field corresponding to the change type (also called the target field) can be determined from at least two fields included in the interface version number of the first interface.

[0048] Step S150: Update the corresponding field value in the interface version number of the first interface according to the field corresponding to the change type.

[0049] According to the field corresponding to the change type, only the field value corresponding to the field in the interface version number of the first interface is updated, thereby achieving accurate update processing of the field.

[0050] Among them, since the code change information can be one or more, the fields that need to be updated can also be one or more, and this application does not limit this.

[0051] It can be seen from this that the present application can automatically determine whether the changes between the interface codes before and after the update are related to the version update according to the preset rules. If it is related to the version update, it means that there is code change information for the second interface code relative to the first interface code. Accordingly, the present application can automatically determine the target field corresponding to the code change type from at least two fields based on the change type of the code change information, thereby achieving accurate update processing of the target field. Therefore, the present application can not only automatically determine whether the version number needs to be updated based on the changes in the interface code, but also automatically determine the target field that needs to be updated in multiple fields based on the code change type of the interface code, thereby achieving rapid and accurate update of the interface version number, thereby avoiding call failures caused by untimely updates of the version number.

[0052] In addition, those skilled in the art may also make various modifications and variations to the method in this application:

[0053] In an optional implementation, when determining the change type of the code change information according to a preset rule, it is specifically implemented in the following manner:

[0054] For any code change information, the change dimension of the code change information is determined based on the rule type of the preset rule that matches the code change information. Furthermore, the change magnitude corresponding to the change dimension is determined based on the change dimension of the code change information, and the change level of the code change information is determined based on the change magnitude. The code change type of the code change information is determined based on the change dimension and change level. The rule type of the preset rule indicates the aspect of the code change that the rule measures, such as logic, performance, or functionality. Correspondingly, the change dimension of the code change information indicates the specific dimension of the code change information, such as logic, performance, or functionality. Because different change dimensions can reflect the type of code change, the type of code change can be used to determine whether the interface version number needs to be updated. Furthermore, the change level is determined based on the change magnitude: a larger change magnitude indicates a higher change level; conversely, a smaller change magnitude indicates a lower change level. Therefore, the change level can be used to determine the impact of a code change. Generally, a higher change level indicates a greater impact, while a lower change level indicates a lower impact. The code change type can be accurately assessed by the change dimension and change level.

[0055] In one optional implementation, code change types include: a first change type and a second change type. Typically, the first change type corresponds to a preset first change dimension, and the second change type corresponds to a preset second change dimension. Furthermore, the change level corresponding to the first change type is higher than the change level corresponding to the second change type. Accordingly, at least two fields include: a first field corresponding to the first change type, and a second field corresponding to the second change type. Furthermore, a change in the first field indicates compatibility between the interface versions before and after the update; a change in the second field indicates incompatibility between the interface versions before and after the update. Thus, the first change type typically refers to a change type that is significant and has a significant impact on the caller. Accordingly, when a change of the first change type occurs, the first field needs to be updated to indicate a significant difference and incompatibility between the interface versions before and after the update. When a change of the second change type occurs, the second field needs to be updated to indicate a minimal difference and compatibility between the interface versions before and after the update. Thus, if the change type is the first change type, the field corresponding to the change type is determined to be the first field of the first change type; if the change type is the second change type, the field corresponding to the change type is determined to be the second field of the second change type.

[0056] In an optional implementation, the rule types of the preset rules include: logic change type, function change type, and performance change type; then the change dimensions of the code change information include: logic change dimension, function change dimension, and performance change dimension. In addition, the first change type corresponds to the preset first type of change dimension, and the second change type corresponds to the preset second type of change dimension. Among them, the first type of change dimension includes: function change dimension and / or logic change dimension; the second type of change dimension includes: logic change dimension and / or performance change dimension. Accordingly, when determining the change dimension of the code change information based on the rule type of the preset rule that matches the code change information, it can be achieved in the following manner: matching the code change information with multiple types of preset rules, determining the rule type of the preset rule that matches the code change information based on the matching results; and determining the change dimension corresponding to the rule type of the matching preset rule based on the preset rule dimension mapping relationship. Among them, the preset rule dimension mapping relationship is used to characterize the correspondence between each type of preset rule and the corresponding change dimension. For example, assume that there are three types of preset rules: function change type preset rules (corresponding to the function change dimension), logic change type preset rules (corresponding to the logic change dimension), and performance change type preset rules (corresponding to the performance change dimension). For example, if the rule type of the preset rule that matches the code change information is the logic change type, then the change dimension of the code change information is the logic change dimension; if the rule type of the preset rule that matches the code change information is the function change type, then the change dimension of the code change information is the function change dimension; if the rule type of the preset rule that matches the code change information is the performance change type, then the change dimension of the code change information is the performance change dimension.

[0057] As can be seen, in general, functional updates and logic changes may lead to major changes in the interface code, resulting in incompatibility between the old and new versions. On the other hand, logic updates and performance changes may lead to minor changes in the interface code, and the versions before and after the changes may still be compatible.

[0058] In an optional implementation, a code comparison result can be determined through static analysis. Accordingly, a code comparison result between a second code analysis result corresponding to the second interface code and a first code analysis result corresponding to the first interface code can be obtained in the following manner: first, a first static analysis result of the first interface code is determined based on a first syntax tree generated from the first interface code. Then, a second static analysis result of the second interface code is determined based on a second syntax tree generated from the second interface code. Finally, a code comparison result is determined based on a static comparison result between the second static analysis result and the first static analysis result.

[0059] A syntax tree is an abstract representation of the grammatical structure of source code. It represents the grammatical structure of a programming language in a tree-like format, with each node in the tree representing a structure in the source code. This is also called an abstract syntax tree. As an important intermediate representation of a program, the basic process of creating a syntax tree can be roughly divided into three steps: first, lexical analysis of the source code (i.e., interface code), syntactic analysis of the word stream generated by lexical analysis, and finally, semantic analysis to form a syntax tree for the source code. As a well-established intermediate representation, the syntax tree contains complete source program information. Lexical analysis, the first stage of the program compilation process, takes the program source code as a character stream as input, scans and analyzes the input character sequence, and ultimately converts it into a word sequence for output. A "word" is the smallest unit of a program. This process does not consider the relationships between words. Lexical analysis provides symbolic nodes for the generation of the abstract syntax tree. Syntactic analysis, the second stage of the program compilation process, primarily performs logical analysis of the program. Its primary task is to analyze the program's basic grammatical structure, such as methods, variables, expressions, and other components, based on the word sequence generated in the first stage and the grammatical rules of the language being analyzed. Semantic analysis is the third stage of the compilation process, which mainly performs logical analysis on the program. The main analysis target is the source program without structural errors. The main analysis method is to perform context-related property verification and type verification on such source programs, mainly to determine whether the source program is semantically accurate.

[0060] It can be seen that the static comparison result is used to characterize the differences between the second interface code and the first interface code at the syntax and statement level. Specifically, when there is a clear difference between the second static analysis result and the first static analysis result, the change type of the code change information of the second interface code relative to the first interface code is further determined based on the difference between the two. The code change information here can be the change point of the second interface code relative to the first interface code determined by static analysis. For example, it can include various situations such as statement change points and logic change points. Accordingly, the code change type of the code change information can be used to characterize the type of change or the way the code change information is changed.

[0061] Accordingly, in the above operation, each logical node in the second static analysis result can be compared with the logical nodes in the first static analysis result. If a logical node in the second static analysis result has changed relative to a logical node in the first static analysis result, the code change type of the code change information of the second interface code relative to the first interface code is determined to be a logical change type. The logical node may include a logical control statement, such as a conditional statement and / or a loop statement. Whether a logical node has changed can be determined by determining that a logical node in the second static analysis result has changed relative to a logical node in the first static analysis result if the difference between the second statement length of the logical control statement in the second static analysis result and the first statement length of the logical control statement in the first static analysis result exceeds a first preset threshold. Alternatively, if the difference between the second statement length of the logical control statement in the second static analysis result and the first statement length of the logical control statement in the first static analysis result exceeds a second preset threshold, the logical node in the second static analysis result can be determined to have changed relative to a logical node in the first static analysis result.

[0062] Optionally, in the above operation, the second static analysis result and each functional module in the first static analysis result can also be compared. When the functional module in the second static analysis result is changed relative to the functional module in the first static analysis result, the code change type of the code change information of the second interface code relative to the first interface code is determined to be a functional change type. Among them, the functional module may include: an algorithm module for characterizing the function implementation algorithm, and a dependency module for characterizing the dependency relationship with the external service. Among them, the algorithm module is used to implement the algorithm logic corresponding to the specified function, and the dependency module is used to call the external service interface to implement the corresponding service function. In short, the functional module is used to implement the specified function of the first interface, which can be implemented by the internal code of the module or by calling an external service.

[0063] In an optional implementation, a code comparison result can be determined through dynamic analysis. Accordingly, a code comparison result between a second code analysis result corresponding to the second interface code and a first code analysis result corresponding to the first interface code can be obtained in the following manner: first, based on first performance indicator data when the first interface code is running, a first dynamic analysis result corresponding to the first interface code is determined. Then, based on second performance indicator data when the second interface code is running, a second dynamic analysis result corresponding to the second interface code is determined. Finally, based on a dynamic comparison result between the second dynamic analysis result and the first dynamic analysis result, a code comparison result is determined.

[0064] Dynamic analysis analyzes the behavior of code while it's running, collecting runtime data by monitoring program execution to identify potential issues and optimize performance. Unlike static analysis, dynamic analysis requires actual code execution, enabling the detection of runtime behavior and states, such as memory usage, performance bottlenecks, and runtime errors. Dynamic analysis tools can help developers identify memory leaks, detect concurrency issues, and analyze the execution time of function calls. For example, dynamic analysis can reveal that a function takes too long to execute under specific inputs, thus facilitating performance optimization. Dynamic analysis provides real-world runtime data, enabling developers to more accurately evaluate and optimize program performance.

[0065] Among them, the performance indicator data is determined based on the time consumed, resource usage, etc. during the program running process. When determining the change type of the code change information of the second interface code relative to the first interface code based on the dynamic comparison result between the second dynamic analysis result corresponding to the second interface code and the first dynamic analysis result corresponding to the first interface code, it can be achieved in the following way: when the change amount between the second performance indicator data and the first performance indicator data exceeds a preset threshold (such as a third preset threshold), the code change type of the code change information of the second interface code relative to the first interface code is determined to be a performance change type. Among them, the performance indicator data can be determined based on data such as memory, CPU, and disk I / O. Among them, the change amount between the second performance indicator data and the first performance indicator data can be measured by percentage, difference, etc., and the preset threshold can be flexibly set according to actual business conditions.

[0066] In an optional implementation, after updating the corresponding field value in the interface version number of the first interface, the interface information corresponding to the first interface is further republished based on the updated interface version number. The republishing operation of the first interface can make the modified new version number effective, thereby facilitating user interface calls based on the new interface version number.

[0067] To facilitate understanding, the following uses an example to describe the technical implementation details in the above embodiment:

[0068] First, let's explain the basic concepts that may be involved in this example:

[0069] Interface Definition: An interface definition is the detailed information used to describe an interface in a software system, typically including the interface name, parameter types, and return value type. This information defines how different software modules or systems communicate and exchange data. The purpose of an interface definition is to ensure that callers and callees have consistent standards when interacting, thereby avoiding misunderstandings and errors. By clearly defining the interface, developers can clearly understand the interface's functionality and usage, thereby improving code readability and maintainability.

[0070] Function Signature: A function signature is a description of the function's name and the types and order of its parameters. It uniquely identifies a function and allows different functions within the same scope to be distinguished. The importance of a function signature lies in ensuring the consistency and correctness of function calls, avoiding runtime errors caused by incorrect parameter types or order. For example, int calculateSum(int a, int b) is a function signature, indicating that the function returns an integer and accepts two integer parameters. A function signature consists of three main parts: the function name (such as calculateSum), the parameter types and order (such as int a, int b), and the return value type (such as int). The function signature allows the compiler to check whether the function call correctly matches its definition, thereby improving the reliability of the code.

[0071] API (Application Programming Interface): An application programming interface (API) is a set of rules and specifications that define how software components communicate with each other. APIs can include functions, methods, protocols, etc., allowing data exchange and function calls between different software modules or systems. The importance of API lies in that it provides a standardized interface that allows different developers or teams to independently develop, test, and integrate their respective modules without having to understand each other's internal implementations. For example, the file operation API provided by the operating system allows applications to perform file read and write operations without having to understand the underlying details of the file system. APIs not only simplify the development process, but also improve the scalability and maintainability of the software, because the standardization of the interface makes it easier to modify or replace the implementation.

[0072] Static Analysis: Static analysis is a method of analyzing source code without executing it to check code quality, identify potential errors, and optimize performance. By parsing and examining the syntax, structure, and style of code, static analysis tools can proactively identify many potential problems, such as syntax errors, unused variables, and potential logic flaws. For example, static analysis can detect uninitialized variables in the code that could cause runtime errors, or identify redundant code and potential performance issues. By performing static analysis during the development process, developers can discover and correct issues at an early stage, reducing debugging and maintenance costs and improving the overall quality and reliability of the software.

[0073] Dynamic Analysis: Dynamic analysis analyzes the behavior of code while it's running, collecting runtime data by monitoring program execution to identify potential issues and optimize performance. Unlike static analysis, dynamic analysis requires actual code execution, enabling the detection of runtime behavior and states, such as memory usage, performance bottlenecks, and runtime errors. Dynamic analysis tools can help developers identify memory leaks, detect concurrency issues, and analyze the execution time of function calls. For example, dynamic analysis can reveal that a function takes too long to execute under specific inputs, thus facilitating performance optimization. Dynamic analysis provides real-world runtime data, enabling developers to more accurately evaluate and optimize program performance.

[0074] Syntax Tree: A syntax tree is a tree-like structure used to represent the grammatical structure of source code. Each node represents a grammatical element in the source code, such as an operator, variable, statement, etc. Syntax trees are an important tool for compilers to perform syntax analysis. By converting source code into a syntax tree, the compiler can more easily understand and process the structure of the code. For example, in the syntax tree of the expression a+b, the root node is the operator +, and its child nodes are the variables a and b. Syntax trees are not only used for syntax checking, but also for subsequent code optimization and machine code generation. Through syntax trees, the compiler can perform complex syntax analysis and transformation to ensure that the code conforms to the grammatical rules of the language and improve compilation and execution efficiency.

[0075] Semantic Versioning: Semantic versioning is a version naming convention that typically uses a three-part version number: major (MAJOR), minor (MINOR), and patch (PATCH). Different parts of the version number reflect different levels of change, helping developers and users understand the compatibility and changes between versions. For example, the major version number is incremented when an incompatible API change is made; the minor version number is incremented when a backwards-compatible new feature is added; and the patch number is incremented when a backwards-compatible bug is fixed. For example, in version 2.1.3, 2 is the major version number, indicating a major change; 1 is the minor version number, indicating a new feature; and 3 is the patch number, indicating a bug fix. By standardizing version naming, semantic versioning helps developers clarify the impact of version upgrades, improving the transparency and predictability of software releases and upgrades. The major version number can be used as a specific implementation of the first field mentioned above, while the version and patch numbers can be used as specific implementations of the second field mentioned above.

[0076] Logical Complexity: Logical complexity refers to the complexity of the logical structure in the code, and is usually measured by the number of special statements such as conditional statements and loop statements in the code. The higher the logical complexity, the more difficult the code is to understand and maintain, and the higher the probability of errors. A commonly used measurement indicator is cyclomatic complexity, which evaluates the complexity of the code by counting the number of independent paths in the code. For example, a function that contains multiple conditional statements and loops has a high logical complexity and is more difficult to maintain. By controlling and reducing logical complexity, developers can improve the readability and maintainability of the code, reduce the possibility of errors, and thus improve the quality and stability of the software.

[0077] Function Path: A function path refers to a series of code paths that a program may follow during execution. Different input conditions may cause the program to execute different code paths. Changes in these paths can lead to different program behavior, making them an important factor in evaluating code changes. The complexity of function paths affects program testing and debugging. For example, multiple conditional branches and loops in a function can lead to multiple different execution paths. To ensure program reliability and correctness, the testing process must cover all possible function paths. By analyzing function paths, developers can identify and optimize critical paths, improve program performance, and reduce potential errors and exceptions. Function path analysis is crucial for ensuring the stability and predictability of software systems.

[0078] In the software development process, the definition and processing of interfaces is an important link. As a bridge for communication between different software modules or systems, the interface (API) version processing is crucial to the normal operation and maintenance of the software. In related technologies, the interface version processing method usually only relies on changes in the interface definition (such as function signature or API description) to determine the interface version. However, the above method has significant shortcomings, namely: it ignores the changes in the interface implementation logic and cannot update the interface version number in a timely manner when the interface definition does not change but the interface logic changes.

[0079] Specifically, interface definitions usually include information such as function names, parameter types, and return value types. Changes in these definitions will indeed affect the version of the interface. However, relying solely on changes in these surface definitions cannot fully reflect the actual changes in the interface. If the interface definition has not changed, but its internal implementation logic has undergone major modifications, such as algorithm optimization, logic adjustments, and the addition of new functions, it may still have an impact on the interface users. For example, the original simple addition operation is changed to a complex calculation process. Although the function signature has not changed, users who call this interface may need to deal with more edge cases or performance changes. Therefore, it is necessary to prompt users of such changes by updating the interface version number.

[0080] This shows that the traditional interface version processing method cannot effectively reflect the actual changes of the interface (when the interface definition remains unchanged, but the internal implementation logic of the interface changes and has a substantial impact on user calls, the interface version number may not be updated in time, causing inconvenience to the user's calls), which may lead to incompatibility issues in interface calls. This incompatibility problem may cause software operation abnormalities, functional failures, and even cause system crashes, seriously affecting user experience and system stability. Therefore, the existing interface version processing method has significant limitations and is in urgent need of improvement.

[0081] To solve the above problems, this example provides an interface version processing method combined with code analysis to achieve automatic updating of interface version numbers. It takes into account changes in interface definitions and changes in interface implementation logic to more accurately process interface versions, thereby improving the reliability and compatibility of the software system.

[0082] Figure 2 The flowchart of the interface version processing method provided in this example is shown as follows: Figure 2 As shown, the method specifically includes the following steps:

[0083] Step S210: When it is identified that the first interface code of the first interface is updated, it is determined whether the interface definition of the first interface is changed.

[0084] Specifically, when the system recognizes that the project code has changed, it determines whether the interface definition of the first interface has changed. Among them, whether the interface definition has changed can be detected in the following way: first, the definition information of the interface is extracted, including the function name, parameter type, return value type, etc. Then, by comparing the interface definition information of the current version (i.e., the latest interface definition) and the interface definition information of the previous version (i.e., the interface definition corresponding to the interface version number before the update), it is determined whether there is a change. For example, for an interface defined as int calculateSum(int a, int b), if the type or number of its parameters changes, it is determined that the interface definition has changed.

[0085] In a specific implementation, whether the interface definition of the first interface has changed can be determined based on a preset interface definition change rule base, wherein the interface definition change rule base is used to store various types of changes in interface definitions, such as changes in the number of parameters, parameter names, return values, and interface names.

[0086] Step S220: Determine whether the interface implementation logic of the first interface has changed.

[0087] Among them, the change detection of interface implementation logic can be achieved in the following ways: first, extract the implementation code of the first interface (i.e., the second interface code mentioned above) and perform static and dynamic analysis on the code. Among them, static analysis evaluates the changes in the code by analyzing the structure and logical complexity of the source code; dynamic analysis monitors its behavior when the code is running and evaluates functional changes. Specifically, a code analysis tool can be used to generate a syntax tree or intermediate representation of the implementation code to detect the change points of the code logic. For example, the addition of a logging function or the optimization of an algorithm, the change of the logical complexity, etc., will be identified as a change in the interface implementation logic. During specific implementation, the change judgment of the interface implementation logic can be performed in combination with a preset interface implementation logic change rule library (also referred to as a logic change rule library, specifically a specific implementation form of the preset rule library mentioned above). Among them, the interface implementation logic change rule library is used to store various changes related to the interface implementation logic change. For example, the interface implementation logic change rule library stores code change features related to logic changes, code change features related to functional changes, code change features related to performance changes, etc. This application does not limit the specific implementation details of the interface implementation logic change rule library, as long as the purpose of detecting changes in the interface implementation logic can be achieved.

[0088] Among them, when determining whether the interface implementation logic of the first interface has changed, it can be determined by matching the code comparison result with the preset preset rule mentioned above. In other words, if the code comparison result matches the preset preset rule, it means that the interface implementation logic of the first interface has changed.

[0089] Step S230: Based on the determination results of whether the interface definition has changed and whether the interface implementation logic has changed, it is determined whether the interface version number of the first interface needs to be updated.

[0090] If the interface definition has changed, it is directly determined that the interface version number of the first interface needs to be updated.

[0091] If the interface definition remains unchanged but the interface implementation logic has changed, that is, if the code comparison results match the preset rules (such as the logic complexity change exceeds a certain percentage, the functional path has changed significantly, etc.), the interface version number will also be determined to need to be updated. This dual determination mechanism ensures the comprehensiveness and accuracy of interface version number updates.

[0092] The interface implementation logic change rule base may be used to implement the above-mentioned determination of the code change type of the code change information of the second interface code relative to the first interface code.

[0093] Step S240: When the interface version number of the first interface needs to be updated, determine the target field to be updated, and update the field value corresponding to the target field in the interface version number of the first interface.

[0094] The preset rules stored in the logic change rule library may include the following:

[0095] 1. Logical structure change rules: for example, conditional statements, loop statements, etc. change.

[0096] Specific rules: If the second interface code adds or deletes logical control statements, such as if-else, switch-case, for, while, do-while, etc., compared with the first interface code, the code comparison result between the second code analysis result corresponding to the second interface code and the first code analysis result corresponding to the first interface code is considered to match the preset rule of the logical change type, and the change dimension of the code change information of the second interface code relative to the first interface code is determined to be the logical change dimension.

[0097] Detection method: First, the static analysis tool parses the code to generate an AST. Then, it traverses the AST to detect added or deleted syntax nodes, such as IfStatement, SwitchStatement, ForStatement, and WhileStatement. If these statements are changed, they are marked as logic changes and the interface version number is updated.

[0098] 2. Functional change rules: for example, algorithm adjustments, function additions and deletions, etc.

[0099] Specific rules: If the second interface code replaces the algorithm or changes the implementation logic of the algorithm relative to the first interface code, the static comparison result between the second static analysis result corresponding to the second interface code and the first static analysis result corresponding to the first interface code is considered to meet the preset rules, and the change dimension of the code change information of the second interface code relative to the first interface code is determined to be the functional change dimension.

[0100] Detection method: (1) Static analysis tools parse the code to generate AST; (2) Static analysis tools parse the configuration file; (3) Identify the core code blocks of the algorithm; (4) Identify the version numbers that the algorithm depends on; (5) Identify the core code blocks that have added functions; (6) Compare the logical complexity and execution path of the new and old code blocks; (7) Compare the version numbers of the algorithm dependencies of the new and old codes to see if there are changes; (8) Compare the new and old codes to see if there are any additions or deletions in the functions. In the above method, the focus is on detecting whether the functions and dependencies of the code have changed. If significant changes in the algorithm logic are detected or there are additions or deletions in the functions, it is marked as a functional change, and the interface version number is updated.

[0101] 3. Performance optimization change rules: For example, the code has been optimized in algorithms, memory, etc., and the logic complexity has changed.

[0102] Specific rules: If the dynamically monitored code performance of the second interface code increases or decreases relative to the first interface code, the code comparison result between the second dynamic analysis result corresponding to the second interface code and the first dynamic analysis result corresponding to the first interface code is considered to meet the preset rules, and the change dimension of the code change information of the second interface code relative to the first interface code is determined to be the performance change dimension.

[0103] Detection method: (1) Static analysis tools parse the code to generate AST; (2) Calculate whether the logical complexity of the code increases or decreases; (3) Calculate whether the spatial complexity of the code increases or decreases; (4) Performance testing tools test the performance indicators of the functional module during operation, and whether the memory, CPU, and disk I / O increase or decrease. If it is detected that the time complexity and space complexity of the code have changed significantly, and the memory, CPU, and disk I / O have changed significantly during operation, it is marked as a performance change, and the interface version number is updated. It can be seen that in actual situations, the performance change type can be determined not only based on dynamic changes, but also based on static changes. In other words, if the static comparison code performance (such as time complexity and space complexity) of the second interface code increases or decreases relative to the first interface code, the static comparison result between the second static analysis result corresponding to the second interface code and the first static analysis result corresponding to the first interface code is considered to meet the preset rules, and the change dimension of the code change information of the second interface code relative to the first interface code is determined to be the performance change dimension.

[0104] 4. Dependency change rules: for example, changes in external interfaces and service dependencies.

[0105] Specific rules: Compared to the first interface code, the second interface code adds or removes references to external libraries and services or method calls. Additionally, since dependencies often lead to functional changes, dependency changes can also be considered a specific case of functional change.

[0106] Detection method: (1) Static analysis tools parse the code to generate an AST; (2) Detect external library imports and method calls; (3) Dynamic analysis tools parse the call chain; (4) Detect the dependencies and dependencies of external services. If a new external dependency is detected, it will be marked as a functional change and the interface version number will be updated.

[0107] 5. Interface security change rules: For example, changes such as adding security checks and fixing security vulnerabilities.

[0108] Specific rules: Compared to the first interface code, the second interface code adds security checks or fixes security vulnerabilities. Interface security changes can also be considered a specific case of functional change type.

[0109] Detection method: (1) Static analysis tools parse the code to obtain an AST; (2) Dynamic code analysis monitors the security check behavior of the code during runtime; (3) Identify new security check code or fixed security vulnerabilities. If new or deleted security check code is detected, it is marked as a security change; if a security vulnerability is detected as a fix, it is marked as a security change. Accordingly, the interface version number is updated.

[0110] 6. Interface monitoring change rules: For example, changes such as new logging and added monitoring code.

[0111] Specific rules: Compared with the first interface code, the second interface code adds logging or monitoring code.

[0112] Detection method: (1) Static analysis tools parse the code into AST; (2) Identify new or deleted log records, such as logger.info and System.out.println; (3) Identify new or deleted monitoring method calls, such as PerformanceMonitor.start and ExceptionMonitor.log; (4) Dynamic analysis tools monitor the log and monitoring behavior of the code during runtime; (5) Identify new logging and monitoring code. If new or deleted logging code is detected, it is marked as a monitoring change; if new or deleted monitoring code is detected, it is marked as a monitoring change. Accordingly, the interface version number is updated. Among them, interface monitoring changes can also be understood as a specific case of functional change type.

[0113] 7. Code refactoring rules: For example, new changes such as design pattern changes, function refactoring, and variable or method renaming have been added.

[0114] Specific rules: New content has been added, including design patterns, function refactoring, variable or method renaming, etc.

[0115] Detection methods: (1) Static analysis tools parse the code to obtain AST; (2) Dynamic analysis tools monitor the behavior of the code at runtime; (3) Identify new design patterns; (4) Identify function extraction or merging operations; (5) Identify name changes of variables or methods.

[0116] Handling method: If a new design pattern is detected, mark it as a refactoring change; if a function refactor is detected, mark it as a refactoring change; if a variable or method name change is detected, mark it as a refactoring change. Accordingly, update the interface version number.

[0117] In the above method, a new interface version number can be generated based on changes in interface definition and implementation logic.

[0118] In an optional implementation, interface version numbers are handled using semantic version numbers (such as MAJOR.MINOR.PATCH): MAJOR indicates a major change, usually caused by a major modification of the interface definition or a major change in the implementation logic. MINOR indicates a minor change, usually caused by a minor modification of the interface definition or a moderate change in the implementation logic. PATCH indicates a revision, usually caused by a minor adjustment to the interface implementation logic.

[0119] Among them, the MAJOR field in the semantic version number indicates a major change, which is usually caused by a major modification of the interface definition or a major change in the interface implementation logic (corresponding to the first change type mentioned above). In addition, these changes will cause backward incompatibility of the interface. The MAJOR field can be a specific implementation form of the first field mentioned above. Among them, the first change type can be specifically determined by the following first-level matching rules:

[0120] Major modifications to an interface definition: (1) removing an existing method or function; (2) changing the signature of a method or function; (3) renaming a method or function in an interface.

[0121] Major changes to the interface implementation logic: (1) Completely rewriting the interface implementation logic; (2) Changing the interface's infrastructure or architecture (e.g., migrating to a different technology stack); (3) Removing key functionality or features.

[0122] The above modifications and changes can all be used as the first change type. When it is detected that the change in the interface code matches the above first-level matching rule, it is determined that the MAJOR field in the semantic version number needs to be updated, that is, the target field is the MAJOR field.

[0123] The MINOR field in the semantic version number indicates a minor change, usually caused by a small modification of the interface definition or a moderate change in the implementation logic (corresponding to the second change type mentioned above). These changes are usually backward compatible, but may introduce new functions or features. The MINOR field can be a specific implementation form of the second field mentioned above. The second change type can be determined specifically by the following second-level matching rules:

[0124] Minor modifications to an interface definition: (1) adding a new method or function; (2) adding optional parameters to an existing method or function; (3) updating the documentation comments of a method or function (without affecting the signature).

[0125] Moderate changes to interface implementation logic: (1) adding new functionality or features without changing the behavior of existing functionality; (2) optimizing existing implementation logic to improve performance or security; (3) using new design patterns or refactoring existing code to improve code quality.

[0126] The above modifications and changes can all be used as the second change type. When it is detected that the change in the interface code matches the above second-level matching rule, it is determined that the MINOR field in the semantic version number needs to be updated, that is, the target field is the MINOR field.

[0127] In addition, the PATCH field in the semantic version number indicates a revision, which is usually caused by a minor adjustment to the interface implementation logic. These changes are usually backward compatible and only involve minor fixes or improvements. Minor adjustments to the interface implementation logic can also be called the third change type. Moreover, these changes will not cause backward incompatibility of the interface. The PATCH field can be a specific implementation form of the third field corresponding to the third change type. Among them, the third change type can be specifically determined by the following third-level matching rules:

[0128] Minor adjustments to interface implementation logic: (1) Fix minor code defects or errors. (2) Optimize existing code to improve code quality. (3) Add logging or monitoring code (without affecting functional behavior).

[0129] It can be seen that each code change type is determined based on a combination of two factors: the change dimension and the change level of the code change information.

[0130] Regardless of whether the target field is the first, second, and / or third field mentioned above, the interface version number must be updated and republished. Specifically, a version release and notification process must be performed: the new interface version number must be published and notified to relevant developers and users. Documentation and version logs can also be used to ensure transparency and traceability of interface changes, facilitating timely code adjustments.

[0131] In summary, this example provides an interface processing method combined with code analysis, which takes into account changes in interface definitions and changes in interface implementation logic to more accurately process interface versions, thereby improving the reliability and compatibility of software systems. In addition, in addition to using semantic version numbers, various other forms of version numbers can also be used. For example, the associated GIT code repository branch information can be used as the version number, that is, the branch + commit id is used as the version number. This application does not limit this.

[0132] It is understood that the various method embodiments mentioned in this application can be combined with each other to form combined embodiments without violating the principle logic. Due to space limitations, this application will not go into details. Those skilled in the art will understand that in the above-mentioned methods of specific implementation, the specific execution order of each step should be determined by its function and possible internal logic.

[0133] In addition, the present application also provides an interface version number update device, an electronic device, and a computer-readable storage medium, all of which can be used to implement any interface processing method provided by the present application. The corresponding technical solutions and descriptions are referred to the corresponding records in the method section and will not be repeated here.

[0134] Figure 3A block diagram of an interface processing device provided in an embodiment of the present application.

[0135] Reference Figure 3 , an embodiment of the present application provides an interface processing device, the interface processing device comprising:

[0136] The detection module 31 is adapted to obtain an updated second interface code of the first interface when detecting that the first interface code of the first interface is updated;

[0137] a comparison module 32, adapted to compare the second interface code with the first interface code to obtain a code comparison result;

[0138] a matching module 33 adapted to determine whether code change information exists in the second interface code if the code comparison result matches a preset rule;

[0139] The determination module 34 is adapted to determine the change type of the code change information according to the preset rule, and determine the field corresponding to the change type from the fields included in the interface version number of the first interface; field

[0140] The updating module 35 is adapted to update a corresponding field value in the interface version number of the first interface according to the field corresponding to the change type.

[0141] In an optional implementation, the determining module is specifically configured to:

[0142] determining a change dimension of the code change information according to a rule type of a preset rule matching the code change information;

[0143] Determining a change amplitude corresponding to the change dimension according to the change dimension of the code change information, and determining a change level of the code change information according to the change amplitude;

[0144] A change type of the code change information is determined according to the change dimension and the change level.

[0145] In an optional implementation, the change type includes: a first change type and a second change type; the change level corresponding to the first change type is higher than the change level corresponding to the second change type; the determining module is specifically configured to:

[0146] In a case where the change type is a first change type, determining that the field corresponding to the change type is a first field of the first change type;

[0147] In a case where the change type is the second change type, determining that the field corresponding to the change type is the second field of the second change type;

[0148] The change of the first field is used to indicate that the interface versions before and after the update are compatible; the change of the second field is used to indicate that the interface versions before and after the update are incompatible.

[0149] In an optional implementation, the rule types of the preset rules include: logic change type, function change type, and performance change type; the change dimensions of the code change information include: logic change dimension, function change dimension, and performance change dimension; the first change type corresponds to a preset first type of change dimension, and the second change type corresponds to a preset second type of change dimension;

[0150] The first type of change dimension includes: functional change dimension and / or logical change dimension; the second type of change dimension includes: logical change dimension and / or performance change dimension;

[0151] The determining module is specifically configured to:

[0152] Matching the code change information with multiple types of preset rules, and determining the rule type of the preset rule that matches the code change information according to the matching result;

[0153] According to the preset rule-dimension mapping relationship, a change dimension corresponding to the rule type of the matching preset rule is determined.

[0154] In an optional implementation, the comparison module is specifically configured to:

[0155] Determine a first static analysis result of the first interface code according to a first syntax tree generated from the first interface code;

[0156] Determine a second static analysis result of the second interface code according to a second syntax tree generated from the second interface code;

[0157] The code comparison result is determined according to a static comparison result between the second static analysis result and the first static analysis result.

[0158] In an optional implementation, the comparison module is specifically configured to:

[0159] Determining a first dynamic analysis result corresponding to the first interface code according to first performance indicator data when the first interface code is running;

[0160] Determining a second dynamic analysis result corresponding to the second interface code according to second performance indicator data when the second interface code is running;

[0161] The code comparison result is determined according to a dynamic comparison result between the second dynamic analysis result and the first dynamic analysis result.

[0162] In an optional implementation, the update module is further configured to:

[0163] The interface information corresponding to the first first interface is republished based on the updated interface version number. Each module in the above-mentioned interface version number updating device can be implemented in whole or in part by software, hardware, or a combination thereof. Each of the above-mentioned modules can be embedded in or independent of a processor in a computer device in the form of hardware, or can be stored in a memory in the computer device in the form of software, so that the processor can call and execute the operations corresponding to each of the above modules.

[0164] Figure 4 A block diagram of an electronic device provided in an embodiment of the present application.

[0165] Reference Figure 4 An embodiment of the present application provides an electronic device, which includes: at least one processor 501; at least one memory 502, and one or more I / O interfaces 503, connected between the processor 501 and the memory 502; wherein the memory 502 stores one or more computer programs that can be executed by the at least one processor 501, and the one or more computer programs are executed by the at least one processor 501 so that the at least one processor 501 can perform the above-mentioned interface processing method.

[0166] Each module in the above-mentioned electronic device can be implemented in whole or in part through software, hardware, or a combination thereof. Each module can be embedded in or independent of the processor in the computer device in hardware form, or can be stored in the memory of the computer device in software form, so that the processor can call and execute the corresponding operations of each module.

[0167] The present application also provides a computer-readable storage medium having a computer program stored thereon, wherein the computer program, when executed by a processor / processing core, implements the above-mentioned interface processing method. The computer-readable storage medium may be a volatile or non-volatile computer-readable storage medium.

[0168] An embodiment of the present application also provides a computer program product, including computer-readable code, or a non-volatile computer-readable storage medium carrying computer-readable code. When the computer-readable code runs in a processor of an electronic device, the processor in the electronic device executes the above-mentioned interface processing method.

[0169] It will be understood by those skilled in the art that all or some of the steps, systems, and functional modules / units in the methods disclosed above may be implemented as software, firmware, hardware, and appropriate combinations thereof. In a hardware implementation, the division between the functional modules / units mentioned in the above description does not necessarily correspond to the division of physical components; for example, a physical component may have multiple functions, or a function or step may be performed by several physical components in cooperation. Some or all physical components may be implemented as software executed by a processor, such as a central processing unit, a digital signal processor, or a microprocessor, or may be implemented as hardware, or may be implemented as an integrated circuit, such as an application-specific integrated circuit. Such software may be distributed on a computer-readable storage medium, which may include a computer storage medium (or non-transitory medium) and a communication medium (or temporary medium).

[0170] As is well known to those skilled in the art, the term computer storage media includes volatile and nonvolatile, removable and non-removable media implemented in any method or technology for storage of information (such as computer-readable program instructions, data structures, program modules or other data). Computer storage media includes, but is not limited to, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM), static random access memory (SRAM), flash memory or other memory technology, portable compact disc read-only memory (CD-ROM), digital versatile disc (DVD) or other optical disc storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium that can be used to store the desired information and can be accessed by a computer. In addition, as is well known to those skilled in the art, communication media typically contains computer-readable program instructions, data structures, program modules or other data in a modulated data signal such as a carrier wave or other transport mechanism, and may include any information delivery media.

[0171] The computer-readable program instructions described herein can be downloaded from a computer-readable storage medium to each computing / processing device, or downloaded to an external computer or external storage device via a network, such as the Internet, a local area network, a wide area network, and / or a wireless network. The network can include copper transmission cables, fiber optic transmission, wireless transmission, routers, firewalls, switches, gateway computers, and / or edge servers. The network adapter card or network interface in each computing / processing device receives the computer-readable program instructions from the network and forwards the computer-readable program instructions to be stored in the computer-readable storage medium in each computing / processing device.

[0172] The computer program instructions for performing the operation of the present application can be assembly instructions, instruction set architecture (ISA) instructions, machine instructions, machine-related instructions, microcode, firmware instructions, state setting data or source code or object code written in any combination of one or more programming languages, wherein the programming language includes object-oriented programming languages ​​such as Smalltalk, C++, and conventional procedural programming languages ​​such as "C" language or similar programming languages. Computer-readable program instructions can be executed completely on the user's computer, partially on the user's computer, executed as an independent software package, partially on the user's computer and partially on a remote computer, or executed completely on a remote computer or server. In the case of a remote computer, the remote computer can be connected to the user's computer by any type of network including a local area network (LAN) or a wide area network (WAN), or can be connected to an external computer (such as by using an Internet service provider to connect to the Internet). In certain embodiments, by utilizing the state information of computer-readable program instructions to personalize electronic circuits, such as programmable logic circuits, field programmable gate arrays (FPGAs) or programmable logic arrays (PLAs), the electronic circuits can execute computer-readable program instructions, thereby realizing various aspects of the present application.

[0173] The computer program product described herein may be implemented in hardware, software, or a combination thereof. In one embodiment, the computer program product is implemented as a computer storage medium. In another embodiment, the computer program product is implemented as a software product, such as a software development kit (SDK).

[0174] Various aspects of the present application are described herein with reference to flowcharts and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the present application. It should be understood that each block of the flowcharts and / or block diagrams, and combinations of blocks in the flowcharts and / or block diagrams, can be implemented by computer-readable program instructions.

[0175] These computer-readable program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing device, thereby producing a machine, so that when these instructions are executed by the processor of the computer or other programmable data processing device, a device is generated that implements the functions / actions specified in one or more blocks in the flowchart and / or block diagram. These computer-readable program instructions can also be stored in a computer-readable storage medium, where these instructions cause the computer, programmable data processing device, and / or other device to operate in a specific manner. Thus, the computer-readable medium storing the instructions comprises an article of manufacture that includes instructions for implementing various aspects of the functions / actions specified in one or more blocks in the flowchart and / or block diagram.

[0176] Computer-readable program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other device so that a series of operational steps are performed on the computer, other programmable data processing apparatus, or other device to produce a computer-implemented process, thereby causing the instructions executed on the computer, other programmable data processing apparatus, or other device to implement the functions / actions specified in one or more blocks in the flowchart and / or block diagram.

[0177] The flow charts and block diagrams in the accompanying drawings show the possible architecture, functions and operations of the system, method and computer program product according to multiple embodiments of the present application. In this regard, each box in the flow chart or block diagram can represent a part of a module, program segment or instruction, and the part of the module, program segment or instruction includes one or more executable instructions for realizing the logical function of the specification. In some alternative implementations, the functions marked in the box can also occur in a sequence different from that marked in the accompanying drawings. For example, two continuous boxes can actually be executed substantially in parallel, and they can sometimes be executed in the opposite order, depending on the functions involved. It should also be noted that each box in the block diagram and / or flow chart, and the combination of the boxes in the block diagram and / or flow chart can be implemented by a special hardware-based system that performs the function or action of the specification, or can be implemented by a combination of special hardware and computer instructions.

[0178] Example embodiments have been disclosed herein, and although specific terms are employed, they are used and should be interpreted only in a general illustrative sense and not for purposes of limitation. In some instances, it will be apparent to those skilled in the art that, unless otherwise expressly indicated, features, characteristics, and / or elements described in conjunction with a particular embodiment may be used alone or in combination with features, characteristics, and / or elements described in conjunction with other embodiments. Therefore, it will be understood by those skilled in the art that various changes in form and detail may be made without departing from the scope of the present application as set forth in the appended claims.

Claims

1. An interface processing method, characterized in that: The method comprises: When it is detected that the first interface code of the first interface is updated, obtaining the updated second interface code of the first interface; Compare the second interface code with the first interface code to obtain a code comparison result; If the code comparison result matches the preset rule, determining that the second interface code has code change information; Determine a change type of the code change information according to the preset rule, and determine a field corresponding to the change type from the fields included in the interface version number of the first interface; The corresponding field value in the interface version number of the first interface is updated according to the field corresponding to the change type.

2. The method according to claim 1, characterized in that Determining the change type of the code change information according to the preset rule includes: Determining a change dimension of the code change information according to a rule type of a preset rule matching the code change information; Determine a change amplitude corresponding to the change dimension according to the change dimension of the code change information, and determine a change level of the code change information according to the change amplitude; A change type of the code change information is determined according to the change dimension and the change level.

3. The method according to claim 2, characterized in that The change type includes: a first change type and a second change type; the change level corresponding to the first change type is higher than the change level corresponding to the second change type; then determining the field corresponding to the change type from the fields included in the interface version number of the first interface includes: In the case where the change type is the first change type, determining that the field corresponding to the change type is the first field of the first change type; the change of the first field is used to indicate that the interface versions before and after the update are compatible; When the change type is the second change type, the field corresponding to the change type is determined to be the second field of the second change type; the change of the second field is used to represent the incompatibility of the interface versions before and after the update.

4. The method according to claim 3, characterized in that The rule types of the preset rules include: logic change type, function change type and performance change type; the change dimensions of the code change information include: logic change dimension, function change dimension and performance change dimension; the first change type corresponds to the preset first type of change dimension, and the second change type corresponds to the preset second type of change dimension; The first type of change dimension includes: functional change dimension and / or logic change dimension; the second type of change dimension includes: logic change dimension and / or performance change dimension; Determining, according to a rule type of a preset rule matching the code change information, a change dimension of the code change information includes: If the rule type of the preset rule matching the code change information is a logic change type, the change dimension of the code change information is a logic change dimension; If the rule type of the preset rule matching the code change information is a function change type, the change dimension of the code change information is a function change dimension; If the rule type of the preset rule matching the code change information is a performance change type, the change dimension of the code change information is a performance change dimension.

5. The method according to claim 3, characterized in that: The comparing the second interface code with the first interface code to obtain a code comparison result comprises: Determine a first static analysis result of the first interface code according to a first syntax tree generated from the first interface code; Determine a second static analysis result of the second interface code according to a second syntax tree generated from the second interface code; The code comparison result is determined according to a static comparison result between the second static analysis result and the first static analysis result.

6. The method according to claim 3, characterized in that The comparing the second interface code with the first interface code to obtain a code comparison result comprises: Determine a first dynamic analysis result corresponding to the first interface code according to first performance indicator data when the first interface code is running; Determine a second dynamic analysis result corresponding to the second interface code according to second performance indicator data when the second interface code is running; The code comparison result is determined according to a dynamic comparison result between the second dynamic analysis result and the first dynamic analysis result.

7. The method according to any one of claims 1 to 6, characterized in that: After the updating of the corresponding field value in the interface version number of the first interface, the method further includes: According to the updated interface version number, the interface information corresponding to the first interface is republished.

8. An interface processing device, characterized in that: The device comprises: A detection module, adapted to, when detecting that a first interface code of a first interface is updated, obtain a second interface code after the first interface is updated; a comparison module, adapted to compare the second interface code with the first interface code to obtain a code comparison result; a matching module, adapted to determine that the second interface code has code change information if the code comparison result matches a preset rule; a determination module, adapted to determine a change type of the code change information according to the preset rule, and determine a field corresponding to the change type from the fields included in the interface version number of the first interface; An updating module is adapted to update a corresponding field value in the interface version number of the first interface according to the field corresponding to the change type.

9. An electronic device, characterized in that: include: at least one processor; as well as a memory communicatively connected to the at least one processor; wherein, The memory stores one or more computer programs that can be executed by the at least one processor, and the one or more computer programs are executed by the at least one processor to enable the at least one processor to execute the interface processing method according to any one of claims 1 to 7.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that: When the computer program is executed by a processor, the computer program implements the interface processing method according to any one of claims 1 to 7.

11. A computer program product, characterized in that The invention comprises a computer-readable code, or a non-volatile computer-readable storage medium carrying the computer-readable code. When the computer-readable code runs in a processor of an electronic device, the processor in the electronic device executes the interface processing method as described in any one of claims 1 to 7.

Images