Interface calling verification method and device, equipment and storage medium

Abstract

The embodiment of the invention provides an interface calling verification method and device, equipment and a storage medium, and the method comprises the steps: obtaining interface query information and a current platform identifier, the interface query information comprising a target interface name and expected calling information; obtaining a preset configuration character string of the target interface name, and analyzing the preset configuration character string to obtain interface configuration information; and respectively comparing the current platform identifier with the expected calling information based on the interface configuration information to determine a verification result. According to the scheme, the compatibility configuration information describing the application programming interface can be stored in the character string format, the storage occupancy rate is reduced, and in addition, the mode of analyzing the configuration character string to obtain the interface configuration information can reduce the analysis complexity and improve the interface calling verification efficiency.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to an interface call verification method, apparatus, device, and storage medium. Background Technology

[0002] With the rapid development of the mobile internet, lightweight embedded applications have become widely popular as a type of application that requires no installation and can be used immediately. These applications rely on a host environment (such as operating system, application version, and hardware device), and different host environments have significantly different levels of support for the programming interfaces, functional components, objects, corresponding methods, and parameters provided by the application. If developers directly call functional modules that are not supported by the current environment, it may lead to program malfunctions, functional failures, or even crashes, severely impacting the user experience. Therefore, a compatibility verification mechanism is needed for function calls to help developers quickly determine the environmental adaptability of target functions at runtime, and then implement targeted degradation processing or functional adaptation strategies to ensure the application's operational stability and cross-environment compatibility.

[0003] In related technologies, compatibility configurations often use structured data formats to store and describe functional support information. However, this type of storage method is prone to problems such as data redundancy and long parsing time, which limits the overall efficiency of functional availability verification. Summary of the Invention

[0004] This application provides an interface call verification method, apparatus, device, and storage medium, which solves the problem that the overall efficiency of functional availability verification is limited due to data redundancy and long parsing time in related technologies. It can use string format to store compatibility configuration information describing application programming interfaces, reducing storage occupancy. Furthermore, the method of parsing the configuration string to obtain interface configuration information can reduce parsing complexity and improve interface call verification efficiency.

[0005] Firstly, embodiments of this application provide an interface call verification method, the method comprising: Obtain interface query information and current platform identifier, wherein the interface query information includes the target interface name and expected call information; Obtain a preset configuration string for the target interface name, and parse the preset configuration string to obtain interface configuration information; Based on the interface configuration information, the current platform identifier and the expected call information are compared to determine the verification result.

[0006] Secondly, embodiments of this application also provide an interface call verification device, the device comprising: The information acquisition module is configured to acquire interface query information and the current platform identifier. The interface query information includes the target interface name and expected call information. The information parsing module is configured to obtain a preset configuration string of the target interface name and parse the preset configuration string to obtain interface configuration information; The verification module is invoked and configured to compare the current platform identifier and the expected call information based on the interface configuration information to determine the verification result.

[0007] Thirdly, embodiments of this application also provide an electronic device, the device comprising: One or more processors; Storage device, configured to store one or more programs, When the one or more programs are executed by the one or more processors, the one or more processors implement the interface call verification method described in the embodiments of this application.

[0008] Fourthly, embodiments of this application also provide a non-volatile storage medium for storing computer-executable instructions, which, when executed by a computer processor, are configured to perform the interface call verification method described in embodiments of this application.

[0009] In this embodiment, by obtaining interface query information including the target interface name and expected call information, and the current platform identifier, a preset configuration string for the target interface name is obtained, which can quickly load the target interface's support capability benchmark information. Parsing the preset configuration string to obtain interface configuration information converts it into comparable structured data, ensuring the accuracy and availability of the benchmark data used for subsequent comparisons. Based on the interface configuration information, the current platform identifier and expected call information are compared to determine the verification result, accurately and comprehensively judging whether the current environment supports the current interface call, ensuring the stability and compatibility of subsequent lightweight embedded applications. The above solution uses string format to store the compatibility configuration information describing the application programming interface, reducing storage usage. Furthermore, the method of parsing the configuration string to obtain the interface configuration information reduces parsing complexity and improves interface call verification efficiency. Attached Figure Description

[0010] Figure 1 A flowchart illustrating an interface call verification method provided in this application embodiment; Figure 2 A flowchart of an interface call verification method, including a process of parsing to obtain interface configuration information, is provided as an embodiment of this application. Figure 3A flowchart illustrating a process for configuring a string based on a second preset symbol and a third preset symbol parsing method, provided in this application embodiment; Figure 4 A flowchart illustrating another process for configuring a string based on a second preset symbol and a third preset symbol parsing method provided in this application embodiment; Figure 5 A flowchart of an interface call verification method provided for embodiments of this application, including a process of configuring a string based on a second preset symbol and a third preset symbol parsing method; Figure 6 A flowchart of an interface call verification method, including a process of comparing and determining the verification result, is provided for an embodiment of this application. Figure 7 A flowchart of an interface call verification method provided for an embodiment of this application, which includes a process of comparing and determining multiple different verification results; Figure 8 A flowchart of an interface call verification method, including a process of checking whether interface configuration information is cached, is provided for an embodiment of this application; Figure 9 A structural block diagram of an interface call verification device provided in an embodiment of this application; Figure 10 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0011] The embodiments of this application will be further described in detail below with reference to the accompanying drawings and examples. It should be understood that the specific embodiments described herein are merely illustrative of the embodiments of this application and are not intended to limit the scope of the embodiments. Furthermore, it should be noted that, for ease of description, only the parts relevant to the embodiments of this application are shown in the accompanying drawings, not the entire structure.

[0012] The terms "first," "second," etc., used in the specification and claims of this application are used to distinguish similar objects and not to describe a specific order or sequence. It should be understood that such use of data can be interchanged where appropriate so that embodiments of this application can be implemented in orders other than those illustrated or described herein, and the objects distinguished by "first," "second," etc., are generally of the same class and the number of objects is not limited; for example, a first object can be one or more. Furthermore, in the specification and claims, "and / or" indicates at least one of the connected objects, and the character " / " generally indicates that the preceding and following objects are in an "or" relationship.

[0013] The interface call verification method provided in this application embodiment can be applied to the multi-platform compatibility judgment process. The execution subject of each step can be a computer device. The computer device refers to any electronic device with data computing, processing and storage capabilities, such as PC (Personal Computer), tablet computer and other terminal devices. This application embodiment does not limit this.

[0014] It should be noted that lightweight embedded applications, as a type of lightweight application, are highly dependent on their host environment for operation. This host environment can be specifically defined as the set of basic conditions that provide operational support for such applications. These include, but are not limited to, the operating system (e.g., different types and versions of operating systems such as Android and iOS) of the terminal device running the application, the host application running the application, and the hardware configuration of the terminal device itself (e.g., processor model, memory capacity, graphics card performance, sensor type, and other hardware-related parameters). However, due to inherent differences in system architecture, development standards, hardware performance, and feature iteration progress among different host environments, their support for the core technical elements required for the operation of such applications exhibits significant inconsistencies. These core technical elements specifically encompass APIs (Application Programming Interfaces), reusable components during application development (e.g., view components, interactive components), objects within the application used to implement specific functions and their associated methods (e.g., method call logic, execution flow), and parameters required during interface calls (e.g., parameter data type, value range, and required fields). If developers fail to anticipate the functional support capabilities of the target host environment when developing such applications, and directly call functional modules corresponding to the aforementioned technical elements that are not supported by the current runtime environment in the application's code logic, then during actual application operation, program runtime exceptions are highly likely to be triggered. This may manifest as runtime error messages, the target functional module failing to execute properly leading to functional malfunction, or even causing the entire application process to terminate, i.e., the program crashes. All of these situations will disrupt the normal usage flow of the application, severely negatively impacting the user experience and consequently reducing user stickiness to such applications. Based on this, in order to solve the above-mentioned application compatibility issues caused by differences in host environments, this application provides an interface call verification method, apparatus, device, and storage medium for performing compatibility verification on the application programming interfaces to be called during the operation of such applications and related technical elements such as components, objects, methods, and parameters. This allows for subsequent targeted execution of downgrade processing strategies (e.g., calling alternative modules with equivalent basic functions) or functional adaptation optimization (e.g., adjusting the functional implementation logic according to the characteristics of the host environment) based on the judgment result, ultimately achieving the technical effect of ensuring the operational stability and compatibility of such applications in different host environments.

[0015] This application provides an environment compatibility verification function (e.g., the canIUse function, checkApiSupport function, etc.) as the core functional judgment tool in the above-mentioned compatibility verification mechanism. It is used to accurately determine whether key technical components to be called during the operation of a lightweight embedded application have usable attributes in the current runtime environment of the lightweight embedded application. These key technical components specifically cover APIs, reusable functional components, objects used to encapsulate specific functional logic, methods bound to these objects for implementing specific operations, and parameters required to be passed during method and interface calls. Specifically, the environment compatibility verification function introduces a structured query string as a query identifier for technical elements. The structured query string uses standardized syntax rules to describe key information such as the type, name, and association of the target technical components, ensuring the accuracy and uniqueness of the query process. Simultaneously, a clear configuration file is used to manage the technical element support list for different host environments. The configuration file contains core data such as the identification information of each host environment, the corresponding technical element support status, and the supported version range. For example, taking the `canIUse` function as an example, calling `canIUse('request.object.abc')` specifically determines whether the "request" interface supports calling the "object" method with the "abc" parameter. In related technologies, the configuration file corresponding to the "request" interface uses JSON object format. Taking an existing technology as an example, a specific example is as follows: { "request": { "platforms": ["ios", "android", "windows", "mac", "devtools"], "methods": { "object": { "params": ["url", "data", "header", "timeout"], "method": { "values": ["GET", "POST", "OPTIONS", "HEAD", "PUT", "DELETE"] } }, "success": { "returns": ["data", "statusCode", "header", "cookies"]} } } The aforementioned configuration file contains approximately 300 characters, making it quite large and relatively slow to load. Furthermore, calling `canIUse('request.object.abc')` to determine if the "request" interface supports the "abc" parameter in the "object" method requires parsing the configuration file, which is complex, requires deep traversal of the object structure, and consumes a lot of memory, potentially impacting runtime performance. Therefore, this embodiment stores the contents of the configuration file in a compact string format, reducing the file size and parsing complexity. To more clearly illustrate the implementation of this step, a specific application example is provided below. Taking the configuration file corresponding to the "request" interface as an example, its configuration information represented in string format is as follows: 'request':*|o:url,data,header,method.GET.POST.OPTIONS.HEAD.PUT.DELETE,timeout;s:data,statusCode,header,cookies'.

[0016] The configuration information represented in string format contains approximately 100 characters, and its size is reduced by 66% compared to the aforementioned JSON object format configuration file, thus reducing memory usage and achieving faster loading.

[0017] Specifically, the following is an example of encoding rules for representing configuration information using a compact string format: "Platform Identifier|Method Type:Parameter List". This configuration format uses separators to clearly divide configuration information into different dimensions, ensuring readability and efficient parsing. The platform identifier specifies the host environment platform to which the current API configuration applies; the method type identifies the supported functionality of the API; and the parameter configuration defines the parameters required during API calls. The platform identifier and method type are separated by the specific symbol "|", and the method type and parameter list are separated by the specific symbol ":". The specific definitions and value rules for each component are as follows: For platform identifiers, the wildcard "*" can be used to indicate that the API configuration is applicable to all types of host environment platforms without platform limitations. The identifier string "mobile" can be used to indicate that the API configuration is only applicable to mobile host environment platforms, including but not limited to host environments corresponding to terminal devices such as mobile phones and tablets running mobile operating systems. The identifier string "pc" can be used to indicate that the API configuration is only applicable to desktop host environment platforms, that is, host environments corresponding to computer terminals running desktop operating systems. Alternatively, a preset numerical code can be used to represent specific platform combinations. Different numbers correspond to different platform combination schemes. The specific platform set corresponding to the number can be looked up through a preset code mapping table. The specific platform can include, but is not limited to, iOS, Android, Windows, Mac, DevTools, etc.

[0018] For method types, different functional implementations can be identified using single characters. Specifically, the character "r" indicates that the API supports the return method, meaning that the API returns the execution result to the caller through a return value after the API call. The character "s" indicates that the API supports the success callback mechanism, meaning that the API returns the result by triggering a preset success callback function after successful execution. The character "o" indicates that the API supports the object parameter type, meaning that an object type parameter needs to be passed during the call. The character "c" indicates that the API supports the callback method, meaning that the relevant logic and results during the API execution process are handled through a callback function.

[0019] For parameter lists, as optional configuration items, they are used to define the parameter information required during API calls. Depending on the number of methods in the API, there are several configuration methods: For a single method scenario, "method name: parameter1, parameter2, ..., parametern" can be used; for multiple methods, "method1 name: parameter1, parameter2, ..., parametern; method2 name: parameter1, parameter2, ..., parameterm" can be used; for nested attribute representation scenarios, when the parameter is an object and contains nested attributes, the symbol "." is used to represent the nesting relationship of the attributes, such as "object name.nested attribute1.nested attribute2", to accurately describe the hierarchical structure of the parameters.

[0020] Here are some examples of configuration information represented in the aforementioned string format: "*|o:timeout,url", "*|o:count;s:tempFilePaths", and "*|o:data;s:data;r:data". In "*|o:timeout,url", the "*" indicates cross-platform compatibility, "o" indicates support for object parameter types, and "timeout,url" indicates that the target API supports object type parameters containing both "timeout" and "url" attributes in all host environments. In "*|o:count;s:tempFilePaths", the "*" indicates cross-platform compatibility, and the method supports both "o" and "s" types. "o:count" indicates passing an object parameter containing a "count" attribute, and "s:tempFilePaths" indicates support for success callback mechanisms, with the callback function returning the "tempFilePaths" parameter, enabling centralized configuration for multiple method support scenarios. The "*" in "*|o:data;s:data;r:data" indicates that it is applicable to all platforms. The method supports three types: "o", "s", and "r", which correspond to "passing in an object parameter with a data attribute", "returning a data parameter via a success callback", and "returning a data parameter via a return method", respectively, enabling a combination of various functional configurations.

[0021] Below is an example of API call validation with the target API being "request". For example, the configuration content corresponding to "request" is "*|o:url,method.GET.POST;s:data". If `canIUse('request.object.url')` is called, this call validates whether the "url" attribute is included in the "object" parameter of "request". Since the configuration explicitly defines "url" in the "object" parameter, the validation result returns "true", indicating that the current environment supports this parameter. If `canIUse('request.success.data')` is called, this call validates whether the "data" parameter is returned in the "success" callback of "request". According to the definition of "s:data" in the configuration, the validation result returns "true", indicating that the current environment supports this callback return parameter. If `canIUse('request.object.abc')` is called, this call validates whether the "abc" attribute is included in the "object" parameter of "request". Since this parameter is not defined in the configuration, the validation result returns "false", indicating that the current environment does not support this parameter.

[0022] Based on the aforementioned string format configuration information storage method, the following details the relevant technical content of the interface call verification method, device, equipment, and storage medium provided in the embodiments of this application.

[0023] Figure 1 A flowchart of an interface call verification method provided in an embodiment of this application is shown below. Figure 1 As shown, the interface call to the verification method includes the following steps: Step S101: Obtain interface query information and current platform identifier. The interface query information includes the target interface name and expected call information.

[0024] The current platform identifier can be the platform identity identifier of the host environment in which the lightweight embedded application is currently running. This is used to accurately distinguish different host environments and avoid compatibility verification errors caused by platform confusion. Specifically, the current platform identifier can be a symbol or numerical code to represent specific platforms including, but not limited to, iOS, Android, Windows, Mac, and DevTools. The interface query information can be a set of query data related to the target interface call required for compatibility verification. Specifically, it includes the target interface name and expected call information. The target interface name can be used to locate the interface to be verified, and the expected call information can be used to describe the details of the interface call logic to be executed. The two combined form complete verification data input. The target interface name can be the unique identifier name of the API that needs to be verified. Specifically, it is an identifier defined according to the system's preset naming conventions during code development and uniquely mapped to the underlying interface implementation logic. This identifier can be used to accurately locate the preset configuration information corresponding to the interface. It should be noted that different interfaces and their corresponding configuration information form a one-to-one correspondence. Each interface can find its corresponding configuration information in the configuration library, i.e., the preset configuration string used in this embodiment. The expected call information can be related to the call logic to be executed on the target interface, including but not limited to the planned method type, the planned parameters, and the planned callback data. It is understood that the purpose of this expected call information is to fully present the details of the interface call behavior to be executed, enabling the subsequent verification process to make targeted judgments based on actual call requirements, avoiding the problem of verification results not matching the actual call scenario due to incomplete descriptions of the call logic. To more clearly illustrate the implementation of this step, the following is explained with a specific application example. Taking the aforementioned call canIUse('request.object.abc') to initiate a compatibility query as an example, the interface query information is "request.object.abc", where the target interface name is "request", and the expected call information is "object.abc".

[0025] Step S102: Obtain the preset configuration string of the target interface name, and parse the preset configuration string to obtain the interface configuration information.

[0026] The preset configuration string can be structured configuration data uniquely bound to the target interface name, pre-written according to a defined unified string encoding format based on the actual supported capabilities of the target interface. This concise and standardized string format integrates various supported capability parameters of the target interface, facilitating storage and management while ensuring the efficiency and accuracy of the parsing process. To more clearly illustrate the implementation of this step, a specific application example is provided below. Taking the previously defined format "Platform Identifier|Method Type:Parameter List" as an example, all interface preset configuration strings follow the same format standard to avoid parsing failures or errors due to inconsistent configuration formats. The preset configuration string for the "request" interface can be "*|o:url,method.GET.POST;s:data", and stored in the corresponding configuration file as baseline data for interface supported capabilities. Following the encoding rules corresponding to this preset configuration string, the interface configuration information can be obtained through reverse parsing. This interface configuration information can be a structured data set describing the supported capabilities of the target interface. Its specific data dimensions can include the platform range supported by the interface, the set of supported method types, and the parameter list corresponding to each method, serving as reference information for subsequent comparison logic.

[0027] Step S103: Based on the interface configuration information, compare the current platform identifier and the expected call information to determine the verification result.

[0028] The process involves comparing the current platform identifier and the expected call information based on the interface configuration information. This aims to verify interface call support from two dimensions: first, whether the current platform identifier is within the platform range supported by the interface; and second, whether the expected call information is within the capabilities supported by the interface. Specifically, it can first determine if the current operating platform is supported by the interface, then determine if the expected call logic is within the interface's capabilities. This progressive comparison order terminates the subsequent comparison if the current platform does not support the interface, avoiding invalid calculations, improving verification efficiency, and ensuring the comprehensiveness and accuracy of the verification results. The verification result can be a judgment result output after comparison, indicating whether the expected call logic is available on the current platform. Specifically, it can be output in Boolean form, for example, "true" indicating availability and "false" indicating unavailability. Of course, in addition to indicating whether the expected call logic is supported, the verification result can also be extended to include detailed information containing reasons for support or non-support; this application does not limit this.

[0029] The above-described method involves obtaining interface query information, including the target interface name and expected call information, along with the current platform identifier. A preset configuration string for the target interface name is then retrieved, allowing for rapid loading of the target interface's support capability baseline information. Parsing the preset configuration string yields interface configuration information, converting it into comparable structured data to ensure the accuracy and availability of the baseline data used for subsequent comparisons. By comparing the current platform identifier and expected call information against the interface configuration information to determine the verification result, the method accurately and comprehensively assesses whether the current environment supports the current interface call, ensuring the stability and compatibility of subsequent lightweight embedded applications. This approach uses string format to store compatibility configuration information describing the application programming interface, reducing storage footprint. Furthermore, parsing the configuration string to obtain the interface configuration information reduces parsing complexity and improves interface call verification efficiency.

[0030] Figure 2 A flowchart of an interface call verification method, including a process of parsing to obtain interface configuration information, is provided for an embodiment of this application. Figure 2 As shown, the interface call to the verification method includes the following steps: Step S201: Obtain interface query information and current platform identifier. The interface query information includes the target interface name and expected call information.

[0031] Step S202: Obtain the preset configuration string for the target interface name.

[0032] Step S203: Identify the first preset character in the preset configuration string, and process the preset configuration string based on the first preset character to obtain the platform identifier string and the method configuration string.

[0033] The first preset character can be a predefined specific separator character used to separate the platform identifier string and the method configuration string in the preset configuration string. To more clearly illustrate the implementation of this step, a specific application example is provided below. Taking the aforementioned string format "platform identifier|method type:parameter list" as an example, the first preset character can be "|", but other characters can also be used, and this application does not limit this. The platform identifier string can be a substring located to one side of the first preset character in the preset configuration string, specifically used to describe the raw character data of the interface's supported platform range. The method configuration string can be a substring located to the other side of the first preset character in the preset configuration string, specifically used to describe the raw character data of the interface's functional implementation capabilities, integrating the interface's supported method types and corresponding parameter list information.

[0034] Step S204: Process the platform identifier string to obtain platform identifier information, and process the method configuration string to obtain method configuration information.

[0035] The platform identification information can define the range of host environment platforms supported by the interface. In one embodiment, based on the encoding rules of the aforementioned configuration information, if the platform identification string contains the wildcard "*", it can be parsed as a structured description of "supporting all platforms"; if the platform identification string contains the identifier string "mobile", it can be parsed as a structured description of "applicable to mobile host environment platforms"; if the platform identification string contains the identifier string "pc", it can be parsed as a structured description of "applicable to desktop host environment platforms"; if the platform identification string is a numeric encoded string, it can be parsed as a specific platform combination, serving as direct reference data for subsequent platform compatibility comparisons. The method configuration information can present the method support details of the interface in key-value pairs or a list, including the set of supported method types and the parameter list corresponding to each method type. For example, the method configuration string "o:url;method.GET.POST;s:data" can be parsed as a structured description of "supporting object parameters (including url and method.GET.POST attributes) and supporting success callbacks (returning data parameters)," serving as direct reference data for subsequent method and parameter compatibility comparisons.

[0036] In one embodiment, Figure 3 A flowchart illustrating a process for configuring a string based on a second preset symbol and a third preset symbol parsing method, as provided in this application embodiment, is shown below. Figure 3 As shown, the specific implementation process of processing the method configuration string to obtain method configuration information includes the following steps: Step S2041: Identify whether the method configuration string contains a second preset symbol and a third preset symbol.

[0037] The second preset symbol can be a predefined specific separator character used to separate the method type identifier and the parameter string. The third preset symbol can be a predefined specific separator character used to separate multiple independent "method type-parameter" combinations. To more clearly illustrate the implementation of this step, the following is explained with a specific application example. Taking the aforementioned string format "Method 1 name: parameter 1, parameter 2, ..., parameter n; Method 2 name: parameter 1, parameter 2, ..., parameter m" as an example, the second preset character can be ":", and the third preset character can be ";". Of course, other characters can also be used, and this application does not limit them. The second preset character can be used to detect whether the current configuration information is formatted correctly, and can also be used to distinguish between method attributes and parameter information. The third preset character can be used to determine whether the method configuration string contains a single method or multiple methods.

[0038] Step S2042: If the method configuration string contains a second preset symbol but does not contain a third preset symbol, process the method configuration string based on the second preset symbol to obtain the method type identifier and parameter string.

[0039] If the method configuration string contains a second preset symbol but not a third preset symbol, it can be considered that the method configuration string contains only a single method. The method configuration string can then be split according to the second preset symbol to obtain the method type identifier and parameter string. To more clearly illustrate the implementation of this step, the following explanation uses a specific application example. Taking the aforementioned string format as an example, the method type identifier can be a single-character identifier, such as "o", "s", "r", "c", etc., where "o" indicates support for the object parameter type, "s" indicates support for the success callback mechanism, "r" indicates support for the return method, and "c" indicates support for the callback method. Of course, the specific character settings and corresponding method types can be adaptively adjusted according to the needs of the actual application scenario, and this application does not impose any limitations on them. The parameter string can describe the parameter information under the corresponding method type, specifically including a single parameter, multiple parameters, or nested attributes, and this application does not impose any limitations on it.

[0040] Step S2043: Integrate the method type identifier and parameter string to obtain method configuration information.

[0041] The integration of method type identifiers and parameter strings aims to associate and combine the split method type identifiers and parameter strings according to a preset data structure, thereby establishing a "method type - parameter list" correspondence. Optionally, the integrated method configuration information can present the support details of a single method in key-value pair format, where the key is the method type identifier and the value is the parameter set parsed from the parameter string. To more clearly illustrate the implementation of this step, a specific application example is used below. Taking the method configuration string "o:url,timeout" as an example, the second preset symbol is ":", which can be split into "o" and "url,timeout", and the corresponding integrated method configuration information is "{"o":[url, timeout]}". Thus, it can be adapted to single-method scenarios, accurately splitting the method configuration string to obtain the method type identifier and parameter string, and forming an association between the independent method type identifier and parameter string.

[0042] In one embodiment, Figure 4 A flowchart illustrating another process for configuring a string based on a second preset symbol and a third preset symbol parsing method provided in this application embodiment is shown below. Figure 4 As shown, after identifying whether the configuration string of the identification method contains the second preset symbol and the third preset symbol, the following steps are also included: Step S2044: If the method configuration string contains a second preset symbol and a third preset symbol, process the method configuration string to obtain multiple sub-configuration strings based on the third preset symbol as the separator.

[0043] If a method configuration string contains both a second preset symbol and a third preset symbol, it can be considered that the method configuration string contains multiple methods. The third preset symbol can be used to split the method configuration string containing multiple methods into multiple syntactically valid single method sub-units, i.e., sub-configuration strings. To more clearly illustrate the implementation of this step, a specific application example is provided below. Taking the method configuration string "o:count;s:tempFilePaths" as an example, with the third preset symbol ";", it can be split into two sub-configuration strings: "o:count" and "s:tempFilePaths". Each sub-configuration string can follow the single-method syntax rule of "method type identifier: parameter string".

[0044] Step S2045: Using the second preset symbol as the separator, process each sub-configuration string to obtain the method type identifier and parameter string.

[0045] Each sub-configuration string contains a single method, which can be split according to the second preset symbol to obtain the method type identifier and parameter string. For details, please refer to the foregoing description; further elaboration is not required here.

[0046] Step S2046: Integrate the method type identifier and parameter string of each sub-configuration string to obtain the method configuration information.

[0047] Each sub-configuration string can be broken down into a method type identifier and parameter strings. These sub-configuration strings are then integrated to form a comprehensive set of multi-method support details. Optionally, the integrated method configuration information can be presented as a key-value dictionary, comprehensively reflecting all methods and parameter information supported by the interface. To more clearly illustrate the implementation of this step, a specific application example is provided below. Taking the method configuration string "o:url,timeout;s:data;r:data" as an example, the sub-configuration strings are "o:url,timeout", "s:data", and "r:data". The corresponding method type identifiers and parameter strings for each sub-configuration string are "o", "url,timeout", "s", "data", "r", and "data", respectively. The integrated method configuration information is "{"o":[url,timeout],"s":[data],"r":[data]}". This approach can adapt to multiple method scenarios, accurately splitting a method configuration string integrating multiple methods into multiple syntactically valid sub-configuration strings, avoiding confusion between the type and parameter information of different methods.

[0048] In one embodiment, after identifying whether the method configuration string contains a second preset symbol and a third preset symbol, the following process is also included: If the method configuration string does not contain the second preset character, the method configuration information will be set to empty.

[0049] If the method configuration string does not contain the second preset character, it can be considered that the method configuration string cannot be separated into the method type identifier and parameter string, which does not conform to the preset basic syntax specifications and belongs to the syntax invalid configuration scenario. Therefore, the method configuration information can be set to empty information. This empty information can be a predefined structured placeholder information used to identify invalid method configuration. Its data structure can be consistent with valid method configuration information. For example, an empty dictionary "{}" can be used to inform subsequent processes that the current method configuration syntax is invalid and there is no available supporting information. Thus, by setting the method configuration information to empty information, a standardized invalid configuration identifier can be provided for subsequent processes, avoiding misjudgments in subsequent comparisons and ensuring the normal progress of the entire compatibility verification process.

[0050] Step S205: Based on the interface configuration information, compare the current platform identifier and the expected call information to determine the verification result.

[0051] As described above, by recognizing the first preset character, the preset configuration string, which mixes platform information and functional information, can be quickly split into independent platform identifier strings and method configuration strings. This allows subsequent parsing processes to efficiently analyze the platform's support scope and functional capabilities separately. Furthermore, by parsing the platform identifier string and method configuration string separately, direct reference data for platform compatibility comparison and method and parameter compatibility comparison can be accurately obtained, providing crucial data support for subsequent verification.

[0052] Figure 5 A flowchart of an interface call verification method, including a process of configuring a string based on a second preset symbol and a third preset symbol parsing method, is provided for embodiments of this application. Figure 5 As shown, the interface call to the verification method includes the following steps: Step S501: Obtain interface query information and current platform identifier. The interface query information includes the target interface name and expected call information.

[0053] Step S502: Obtain the preset configuration string for the target interface name.

[0054] Step S503: Identify the first preset character in the preset configuration string, and process the preset configuration string based on the first preset character to obtain the platform identifier string and the method configuration string.

[0055] Step S504: Process the platform identifier string to obtain the platform identifier information.

[0056] Step S505: Identify whether the method configuration string contains a second preset symbol and a third preset symbol; Step S506: If the method configuration string contains a second preset symbol but does not contain a third preset symbol, process the method configuration string based on the second preset symbol to obtain the method type identifier and parameter string; Step S507: Integrate the method type identifier and parameter string to obtain method configuration information.

[0057] Step S508: If the method configuration string contains a second preset symbol and a third preset symbol, process the method configuration string to obtain multiple sub-configuration strings based on the third preset symbol as the separator. Step S509: Using the second preset symbol as the separator, process each sub-configuration string to obtain the method type identifier and parameter string; Step S510: Integrate the method type identifier and parameter string of each sub-configuration string to obtain method configuration information.

[0058] Step S511: If the method configuration string does not contain the second preset character, set the method configuration information to empty information.

[0059] Step S512: Based on the interface configuration information, compare the current platform identifier and the expected call information to determine the verification result.

[0060] It should be noted that step S504 can be executed in parallel with steps S505-S511, while steps S506-S507, S508-S510, and S511 can correspond to various parallel cases of whether or not the second preset symbol and the third preset symbol are included. If the method configuration string contains the second preset symbol but not the third preset symbol, it can be considered that the method configuration string contains only a single method, and the method configuration string can be split to obtain the method type identifier and parameter string according to the second preset symbol. If the method configuration string contains both the second and third preset symbols, it can be considered that the method configuration string contains multiple methods, and the method configuration string integrating multiple methods can be split into multiple syntactically valid single method sub-units, i.e., sub-configuration strings, according to the third preset symbol. If the method configuration string does not contain the second preset symbol, it can be considered that the method configuration string cannot be split into the method type identifier and parameter string, which does not conform to the preset basic syntax rules and belongs to the syntactically invalid configuration scenario. Therefore, it can adapt to different possible combinations of whether or not the second and third preset symbols are included in the generation process of the corresponding method configuration information, accurately and efficiently complete the parsing and processing of the method configuration string, and provide reliable reference information for subsequent compatibility comparison.

[0061] Figure 6A flowchart of an interface call verification method, including a process of comparing and determining the verification result, is provided for an embodiment of this application. Figure 6 As shown, the interface call to the verification method includes the following steps: Step S601: Obtain interface query information and current platform identifier. The interface query information includes the target interface name and expected call information.

[0062] Step S602: Obtain the preset configuration string of the target interface name, parse the preset configuration string to obtain the interface configuration information, wherein the interface configuration information includes platform identification information and method configuration information.

[0063] Step S603: Compare the current platform identifier with the platform identifier information. If the current platform identifier is within the platform range defined by the platform identifier information, compare the expected call information with the method configuration information.

[0064] The current platform identifier can be the identity of the host environment currently running the lightweight embedded application, while the platform identifier information can clearly define the range of host environments supported by the target interface. By comparing the current platform identifier and the platform identifier information, it can be determined whether the current platform identifier is within the platform range defined by the platform identifier information. This allows for pre-filtering of invalid scenarios, prioritizing the exclusion of platform incompatibility cases, and continuing with subsequent configuration information comparisons while ensuring the validity of the runtime environment. If the current platform identifier is within the platform range defined by the platform identifier information, it can be considered that the current platform is within the supported range, the platform verification passes, and the comparison of expected call information and method configuration information can continue.

[0065] Step S604: If the method configuration information includes the expected method and expected parameters in the expected call information, determine that the verification result is successful.

[0066] If the method configuration information includes the expected call method and expected call parameters from the expected call information, it can be considered that both the expected call method and expected call parameters are within the range supported by the interface. Therefore, the verification result is "verification passed," indicating that the expected call can be executed normally. To more clearly illustrate the implementation of this step, the following is an explanation with a specific application example. Taking the method configuration string "o:url,timeout;s:data;r:data" as an example, the corresponding parsed method configuration information is "{"o":[url,timeout],"s":[data],"r":[data]}". If the expected call information is "success.data", then the expected call method is "success" and the expected call parameter is "data". Since the method configuration information already records the same call method and call parameters, i.e., ""s":[data]", it can be determined that the verification result is "verification passed".

[0067] In one embodiment, after comparing the current platform identifier with the platform identifier information, the method further includes: If the current platform identifier is not within the platform scope defined by the platform identifier information, the verification result is determined to be verification failure.

[0068] If the current platform identifier is not within the platform range specified by the platform identifier information, it can be considered that the current platform is not supported and the platform verification fails. There is no need to compare the expected call information with the method configuration information in the subsequent process. The verification result can be directly determined as verification failure, thus achieving efficient verification result judgment.

[0069] In one embodiment, after comparing the expected invocation information with the method configuration information, the method further includes: If the method configuration information does not contain the expected method or expected parameters in the expected invocation information, the verification result is determined to be verification failure.

[0070] If the method configuration information does not contain the expected call method or expected call parameters from the expected call information, it can be considered that the expected call method or expected call parameters are not within the scope of interface support. Therefore, the verification result is verification failure, indicating that the expected call cannot be executed normally. To more clearly illustrate the implementation method of this step, the following is explained with a specific application example. Taking the method configuration string as "o:url,timeout;s:data;r:data" as an example, the corresponding parsed method configuration information is "{"o":[url,timeout],"s":[data],"r":[data]}". If the expected call information is "object.abc", then the expected call method is "object" and the expected call parameter is "abc". However, the method configuration information does not record this preset call parameter in the object method type. Therefore, it can be determined that the verification result is verification failure.

[0071] As described above, by comparing the parsed platform identifier information and method configuration information with the current platform identifier and expected call information respectively, hierarchical and orderly verification can be performed. By comparing the platform identifier, scenarios where the interface is not supported by the current platform can be quickly excluded, avoiding invalid call attempts. By comparing the expected call information with the method configuration information, it can be further determined whether there are compatibility issues, providing accurate verification results.

[0072] Figure 7 A flowchart of an interface call verification method, including a process of comparing and determining multiple different verification results, is provided for an embodiment of this application. Figure 7 As shown, the interface call to the verification method includes the following steps: Step S701: Obtain interface query information and current platform identifier. The interface query information includes the target interface name and expected call information.

[0073] Step S702: Obtain the preset configuration string of the target interface name, parse the preset configuration string to obtain the interface configuration information, wherein the interface configuration information includes platform identification information and method configuration information.

[0074] Step S703: Compare the current platform identifier with the platform identifier information.

[0075] Step S704: If the current platform identifier is not within the platform range defined by the platform identifier information, the verification result is determined to be verification failure.

[0076] Step S705: If the current platform identifier is within the platform range defined by the platform identifier information, compare the expected call information with the method configuration information.

[0077] Step S706: If the method configuration information includes the expected method and expected parameters in the expected call information, determine that the verification result is successful.

[0078] Step S707: If the method configuration information does not contain the expected method or expected parameters in the expected call information, the verification result is determined to be verification failure.

[0079] It should be noted that steps S704 and S705-S707 are parallel cases, as are steps S706 and S707. If the current platform identifier is not within the platform range defined by the platform identifier information, it can be considered that the current platform is not within the supported range, and the platform verification fails. There is no need to further compare the expected call information with the method configuration information; the verification result can be directly determined as verification failure. If the current platform identifier is within the platform range defined by the platform identifier information, it can be considered that the current platform is within the supported range, and the platform verification passes. The comparison of the expected call information with the method configuration information can continue. If the method configuration information includes the expected call method and expected call parameters from the expected call information, it can be considered that both the expected call method and expected call parameters are within the interface's supported range. Therefore, the verification result is verification pass, indicating that the expected call can be executed normally. If the method configuration information does not include the expected call method or expected call parameters from the expected call information, it can be considered that the expected call method or expected call parameters are not within the interface's supported range. Therefore, the verification result is verification failure, indicating that the expected call cannot be executed normally. Therefore, the corresponding verification results can be determined according to different comparison results, providing a reference for subsequent downgrade processing or function adaptation.

[0080] Figure 8 A flowchart of an interface call verification method, including a process of checking whether interface configuration information is cached, is provided for embodiments of this application. Figure 8 As shown, the interface call to the verification method includes the following steps: Step S801: Obtain interface query information and current platform identifier. The interface query information includes the target interface name and expected call information.

[0081] Step S802: Check whether the interface configuration information of the target interface name is cached.

[0082] Since users may query and validate the configuration information of the same interface using different methods or parameters, this could lead to repeated parsing of the same interface's configuration information. Therefore, it's advisable to first check if the parsed interface configuration information is already cached. If the interface configuration information corresponding to the target interface name is cached, there's no need to query the corresponding configuration string for parsing; the cached result can be reused directly.

[0083] Step S803: If interface configuration information with the target interface name is detected in the cache, obtain the interface configuration information, and compare the current platform identifier and the expected call information based on the interface configuration information to determine the verification result.

[0084] If the cache contains interface configuration information corresponding to the target interface name, it can be considered a hit in the cache. The interface configuration information obtained from the cache is used as the basis to complete the compatibility check and determine the result.

[0085] Step S804: If the interface configuration information of the target interface name is not cached, obtain the preset configuration string of the target interface name, and parse the preset configuration string to obtain the interface configuration information.

[0086] If no cached interface configuration information for the target interface name is detected, it can be considered a cache miss, and the subsequent parsing process can continue to obtain the corresponding interface configuration information.

[0087] Step S805: Based on the interface configuration information, compare the current platform identifier and the expected call information to determine the verification result.

[0088] It should be noted that steps S803 and S804-S805 are parallel processes. Therefore, by checking the cache, duplicate parsing of configuration information for the same interface can be avoided, improving the overall efficiency of compatibility verification and efficiently reusing the parsing results of the same interface.

[0089] Figure 9 This is a structural block diagram of an interface call verification device provided in an embodiment of this application. The device is configured to execute the interface call verification method provided in the above embodiment, and has corresponding functional modules and beneficial effects for executing the method. For example... Figure 9 As shown, the device specifically includes: The information acquisition module 901 is configured to acquire interface query information and the current platform identifier. The interface query information includes the target interface name and expected call information. The information parsing module 902 is configured to obtain a preset configuration string for the target interface name and parse the preset configuration string to obtain the interface configuration information. The verification module 903 is invoked and configured to compare the current platform identifier and the expected call information based on the interface configuration information to determine the verification result.

[0090] The above-described method involves obtaining interface query information, including the target interface name and expected call information, along with the current platform identifier. A preset configuration string for the target interface name is then retrieved, allowing for rapid loading of the target interface's support capability baseline information. Parsing the preset configuration string yields interface configuration information, converting it into comparable structured data to ensure the accuracy and availability of the baseline data used for subsequent comparisons. By comparing the current platform identifier and expected call information against the interface configuration information to determine the verification result, the method accurately and comprehensively assesses whether the current environment supports the current interface call, ensuring the stability and compatibility of subsequent lightweight embedded applications. This approach uses string format to store compatibility configuration information describing the application programming interface, reducing storage footprint. Furthermore, parsing the configuration string to obtain the interface configuration information reduces parsing complexity and improves interface call verification efficiency.

[0091] In one possible embodiment, the interface configuration information includes platform identification information and method configuration information; the information parsing module 902 is further configured as follows: Identify the first preset character in the preset configuration string, and process the preset configuration string based on the first preset character to obtain the platform identifier string and the method configuration string; The platform identifier string is processed to obtain the platform identifier information, and the method configuration string is processed to obtain the method configuration information.

[0092] In one possible embodiment, the information parsing module 902 is further configured as follows: The identification method configuration string is used to determine whether it contains a second preset symbol and a third preset symbol. If the method configuration string contains a second preset symbol but does not contain a third preset symbol, the method configuration string is processed based on the second preset symbol to obtain the method type identifier and parameter string; The method configuration information is obtained by combining the method type identifier and parameter string.

[0093] In one possible embodiment, a first configuration information determination module is further included, configured as follows: If the method configuration string contains a second preset symbol and a third preset symbol, the method configuration string is processed to obtain multiple sub-configuration strings based on the third preset symbol as the delimiter; Using the second preset symbol as the separator, each sub-configuration string is processed to obtain the method type identifier and parameter string; The method configuration information is obtained by integrating the method type identifier and parameter string of each sub-configuration string.

[0094] In one possible embodiment, a second configuration information determination module is further included, configured as follows: If the method configuration string does not contain the second preset character, the method configuration information will be set to empty.

[0095] In one possible embodiment, the interface configuration information includes platform identification information and method configuration information; the call verification module 903 is further configured as follows: The current platform identifier is compared with the platform identifier information. If the current platform identifier is within the platform scope defined by the platform identifier information, the expected call information is compared with the method configuration information. If the method configuration information includes the expected method and expected parameters from the expected invocation information, the verification result is determined to be successful.

[0096] In one possible embodiment, a first verification module is further included, configured as follows: If the current platform identifier is not within the platform scope defined by the platform identifier information, the verification result is determined to be verification failure.

[0097] In one possible embodiment, a second verification module is also included, configured as follows: If the method configuration information does not contain the expected method or expected parameters in the expected invocation information, the verification result is determined to be verification failure.

[0098] In one possible embodiment, a cached call verification module is also included, configured as follows: Check if the interface configuration information for the target interface name is cached; If the cached interface configuration information of the target interface name is detected, the interface configuration information is obtained, and the current platform identifier and the expected call information are compared based on the interface configuration information to determine the verification result. The information parsing module 902 is also configured as follows: If the interface configuration information for the target interface name is not cached, obtain the preset configuration string for the target interface name.

[0099] Figure 10 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application, such as... Figure 10 As shown, the device includes a processor 1001, a memory 1002, an input device 1003, and an output device 1004; the number of processors 1001 in the device can be one or more. Figure 10 Taking a processor 1001 as an example; the processor 1001, memory 1002, input device 1003, and output device 1004 in the device can be connected via a bus or other means. Figure 10Taking a bus connection as an example, the memory 1002, as a computer-readable storage medium, can be configured to store software programs, computer-executable programs, and modules, such as the program instructions / modules corresponding to the interface call verification method in this embodiment. The processor 1001 executes various functional applications and data processing of the device by running the software programs, instructions, and modules stored in the memory 1002, thereby implementing the aforementioned interface call verification method. The input device 1003 can be configured to receive input digital or character information and generate key signal inputs related to user settings and function control of the device. The output device 1004 may include a display screen or other display device.

[0100] The electronic device provided above can be used to execute the interface call verification method provided in any of the above embodiments, and has the corresponding functions and beneficial effects.

[0101] This application also provides a non-volatile storage medium containing computer-executable instructions. When executed by a computer processor, the computer-executable instructions are configured to perform an interface call verification method described in the above embodiments. The method includes: obtaining interface query information and a current platform identifier, wherein the interface query information includes a target interface name and expected call information; obtaining a preset configuration string of the target interface name, parsing the preset configuration string to obtain interface configuration information; and comparing the current platform identifier and the expected call information based on the interface configuration information to determine the verification result.

[0102] Storage medium – any type of memory device or storage device. The term “storage medium” is intended to include: mounting media, such as CD-ROMs, floppy disks, or magnetic tape devices; computer system memory or random access memory, such as DRAM, DDR RAM, SRAM, EDO RAM, Rambus RAM, etc.; non-volatile memory, such as flash memory, magnetic media, optical storage; registers or other similar types of memory elements, etc. Storage media may also include other types of memory or combinations thereof. Furthermore, storage media may reside in a first computer system in which the program is executed, or may reside in a different second computer system connected to the first computer system via a network (such as the Internet). The second computer system can provide program instructions to the first computer for execution. The term “storage medium” can include two or more storage media residing in different locations (e.g., in different computer systems connected via a network). Storage media may store program instructions (e.g., specifically implemented as a computer program) executable by one or more processors.

[0103] Of course, the computer-executable instructions provided in the embodiments of this application are not limited to the interface call verification method described above, but can also perform related operations in the interface call verification method provided in any embodiment of this application, and have corresponding functions and beneficial effects.

[0104] It should be noted that the numbering of each step in this solution is only used to describe the overall design framework of this solution and does not indicate a necessary sequential relationship between the steps. As long as the overall implementation process conforms to the overall design framework of this solution, it falls within the protection scope of this solution. The literal order in the description is not an exclusive limitation on the specific implementation process of this solution. Those skilled in the art should understand that the embodiments of this application can be provided as methods, systems, or computer program products. In a typical configuration, a computing device includes one or more processors (CPUs), input / output interfaces, network interfaces, and memory. Memory may include non-persistent memory in computer-readable media, random access memory (RAM), and / or non-volatile memory, such as read-only memory (ROM) or flash RAM. Memory is an example of computer-readable media.

[0105] It should also be noted that the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such process, method, article, or apparatus. Unless otherwise specified, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes that element.

[0106] Note that the above description is merely a preferred embodiment of the present invention and the technical principles employed. Those skilled in the art will understand that the present invention is not limited to the specific embodiments described herein, and various obvious changes, readjustments, and substitutions can be made without departing from the scope of protection of the present invention. Therefore, although the present invention has been described in detail through the above embodiments, the present invention is not limited to the above embodiments, and may include many other equivalent embodiments without departing from the concept of the present invention, the scope of which is determined by the scope of the appended claims.

Claims

1. An interface call verification method, characterized in that, include: Obtain interface query information and current platform identifier, wherein the interface query information includes the target interface name and expected call information; Obtain a preset configuration string for the target interface name, and parse the preset configuration string to obtain interface configuration information; Based on the interface configuration information, the current platform identifier and the expected call information are compared to determine the verification result.

2. The interface call verification method according to claim 1, characterized in that, The step of parsing the preset configuration string to obtain the interface configuration information includes: Identify the first preset character in the preset configuration string, and process the preset configuration string based on the first preset character to obtain the platform identifier string and the method configuration string; The platform identifier string is processed to obtain platform identifier information, and the method configuration string is processed to obtain method configuration information.

3. The interface call verification method according to claim 2, characterized in that, The process of processing the method configuration string to obtain method configuration information includes: Identify whether the method configuration string contains a second preset symbol and a third preset symbol; If the method configuration string contains the second preset symbol but does not contain the third preset symbol, the method configuration string is processed based on the second preset symbol to obtain the method type identifier and parameter string; The method configuration information is obtained by integrating the method type identifier and the parameter string.

4. The interface call verification method according to claim 3, characterized in that, After identifying whether the method configuration string contains a second preset symbol and a third preset symbol, the method further includes: If the method configuration string contains the second preset symbol and the third preset symbol, the method configuration string is processed to obtain multiple sub-configuration strings based on the third preset symbol as the delimiter; Using the second preset symbol as the separator, each sub-configuration string is processed to obtain the method type identifier and parameter string; The method configuration information is obtained by integrating the method type identifier and parameter string of each of the sub-configuration strings.

5. The interface call verification method according to claim 3, characterized in that, After identifying whether the method configuration string contains a second preset symbol and a third preset symbol, the method further includes: If the method configuration string does not contain the second preset character, the method configuration information is set to empty information.

6. The interface call verification method according to claim 1, characterized in that, The interface configuration information includes platform identification information and method configuration information; The step of comparing the current platform identifier and the expected call information based on the interface configuration information to determine the verification result includes: The current platform identifier is compared with the platform identifier information. If the current platform identifier is within the platform range defined by the platform identifier information, the expected call information is compared with the method configuration information. If the method configuration information includes the expected method and expected parameters in the expected invocation information, the verification result is determined to be successful.

7. The interface call verification method according to claim 6, characterized in that, After comparing the current platform identifier with the platform identifier information, the method further includes: If the current platform identifier is not located within the platform range defined by the platform identifier information, the verification result is determined to be verification failure.

8. The interface call verification method according to claim 6, characterized in that, After comparing the expected invocation information with the method configuration information, the method further includes: If the method configuration information does not contain the expected call method or expected call parameters in the expected call information, the verification result is determined to be verification failure.

9. The interface call verification method according to any one of claims 1-8, characterized in that, Before obtaining the preset configuration string of the target interface name, the method further includes: Check whether the interface configuration information for the target interface name is cached; If the interface configuration information of the target interface name is detected in the cache, the interface configuration information is obtained, and the current platform identifier and the expected call information are compared based on the interface configuration information to determine the verification result; The preset configuration string for obtaining the target interface name includes: If it is detected that the interface configuration information for the target interface name is not cached, the preset configuration string for the target interface name is obtained.

10. An interface call verification device, characterized in that, include: The information acquisition module is configured to acquire interface query information and the current platform identifier. The interface query information includes the target interface name and expected call information. The information parsing module is configured to obtain a preset configuration string of the target interface name and parse the preset configuration string to obtain interface configuration information; The verification module is invoked and configured to compare the current platform identifier and the expected call information based on the interface configuration information to determine the verification result.

11. An electronic device, characterized in that, The device includes: one or more processors; and a storage device configured to store one or more programs, which, when executed by the one or more processors, cause the one or more processors to implement the interface call verification method according to any one of claims 1-9.

Images