CN113076134A

CN113076134A - API change monitoring method, system, client and electronic equipment

Info

Publication number: CN113076134A
Application number: CN202110378261.7A
Authority: CN
Inventors: 杨皓
Original assignee: Guangzhou Huya Technology Co Ltd
Current assignee: Guangzhou Huya Technology Co Ltd
Priority date: 2021-04-08
Filing date: 2021-04-08
Publication date: 2021-07-06

Abstract

The application provides an API change monitoring method, a system, a client and an electronic device, wherein the method comprises the following steps: calling a target API, and performing syntax analysis on target API return data to obtain a data structure of the return data; and determining whether the data structure of the returned data is consistent with a pre-stored data structure to monitor the change event of the target API, wherein the pre-stored data structure is determined based on the data structure of the called historical returned data of the target API. According to the method, the change of the target API is monitored by performing syntactic analysis on the returned data of the target API to obtain the data structure and comparing the data structure of the returned data with the prestored data structure, so that the API document is not required to be maintained by manual intervention, and the automatic monitoring of the API change is realized.

Description

API change monitoring method, system, client and electronic equipment

Technical Field

The present application relates to the field of computer technologies, and in particular, to an API change monitoring method, system, client, and electronic device.

Background

An Application Programming Interface (API) is a predefined Interface, and can implement mutual communication and data sharing between computer software and between different platforms. The application developer can call the functions developed by other software providers through the open API. Changes to the API are often difficult to perceive and require a significant amount of human labor to maintain the API documentation. However, in the face of a large number of API documents, it is difficult for developers to independently and efficiently maintain a large number of API documents, and the development is prone to careless mistakes. If the developer fails to process the changed API in time, the whole application system may be crashed. In the related art, no technology capable of automatically sensing API changes exists.

Disclosure of Invention

The application provides an API change monitoring method, system, client and electronic equipment, which can automatically monitor API change events.

According to a first aspect of embodiments of the present application, there is provided an API change monitoring method, including:

calling a target API, and performing syntax analysis on target API return data to obtain a data structure of the return data;

and determining whether the data structure of the returned data is consistent with a pre-stored data structure to monitor the change event of the target API, wherein the pre-stored data structure is determined based on the data structure of the called historical returned data of the target API.

According to a second aspect of the embodiments of the present application, an API change monitoring system is provided, where the system includes a client and a server, and the server is loaded with at least one API;

the server is used for storing the related data of the API and returning response data when receiving a call request of the client to the target API;

the client is used for pre-storing a data structure of historical return data of a called target API, sending a request for calling the target API in the server, performing syntax analysis on response data returned by the target API, obtaining the data structure of the return data, and determining whether the data structure of the return data is consistent with a pre-stored data structure or not so as to monitor a change event of the target API in the server, wherein the pre-stored data structure is determined based on the data structure of the called historical return data of the target API.

According to a third aspect of embodiments of the present application, there is provided a client, including:

the analysis module is used for calling a target API and carrying out syntactic analysis on the returned data of the target API to obtain a data structure of the returned data;

and the monitoring module is used for determining whether the data structure of the returned data is consistent with a pre-stored data structure so as to monitor the change event of the target API, and the pre-stored data structure is determined based on the called data structure of the historical returned data of the target API.

According to a fourth aspect of embodiments of the present application, there is provided an electronic apparatus, including:

a processor;

a memory for storing processor-executable instructions;

wherein the processor is configured to:

The technical scheme provided by the embodiment of the application can have the following beneficial effects:

according to the API change monitoring method, the API change monitoring system, the API change monitoring client side and the electronic equipment, grammatical analysis is carried out on returned data responded by a target API aiming at a call request, a data structure of the returned data is obtained, the data structure of the returned data is compared with a pre-stored data structure, whether a change event occurs to the target API is monitored, accordingly, manual intervention is not needed to maintain an API document, and automatic monitoring of API change is achieved.

It is to be understood that both the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the application.

Drawings

The accompanying drawings, which are incorporated in and constitute a part of this application, illustrate embodiments consistent with the present application and together with the description, serve to explain the principles of the application.

Fig. 1 is a flowchart illustrating an API change monitoring method according to an exemplary embodiment of the present application.

FIG. 2 is a flowchart illustrating the data structure banking step illustrated herein in accordance with an exemplary embodiment.

Fig. 3 is a flowchart illustrating an API change monitoring method according to another exemplary embodiment of the present application.

Fig. 4 is a flowchart illustrating an API change monitoring method according to another exemplary embodiment of the present application.

FIG. 5 is a block diagram illustrating an API change monitoring system in accordance with an exemplary embodiment of the present application.

FIG. 6 is a block diagram of a client shown in accordance with an exemplary embodiment of the present application.

FIG. 7 is a block diagram of hardware of an electronic device according to an exemplary embodiment of the present application.

Detailed Description

Reference will now be made in detail to the exemplary embodiments, examples of which are illustrated in the accompanying drawings. When the following description refers to the accompanying drawings, like numbers in different drawings represent the same or similar elements unless otherwise indicated. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with the present application. Rather, they are merely examples of apparatus and methods consistent with certain aspects of the present application, as detailed in the appended claims.

The terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting of the application. As used in this application and the appended claims, the singular forms "a", "an", and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise. It should also be understood that the term "and/or" as used herein refers to and encompasses any and all possible combinations of one or more of the associated listed items.

It is to be understood that although the terms first, second, third, etc. may be used herein to describe various information, such information should not be limited to these terms. These terms are only used to distinguish one type of information from another. For example, first information may also be referred to as second information, and similarly, second information may also be referred to as first information, without departing from the scope of the present application. The word "if" as used herein may be interpreted as "at … …" or "when … …" or "in response to a determination", depending on the context.

Next, examples of the present application will be described in detail.

An Application Programming Interface (API) may implement communication and data sharing between computer software and between different platforms. The developer will make changes to the API as needed, and the BUG in the development program will also cause unexpected changes to the API. The change of the API refers to the change of the API underlying data, and comprises the addition and the reduction of API fields, the change of the field types and the content, and the switching between the available state and the unavailable state of the API. With the popularity of microservices, it is important to sense the change of the API in time after development and release, and if the API change is not found in time due to a problem in development, or a front-end developer fails to obtain the API change information in time after a back-end developer changes the API, the whole application system may be crashed. In the related art, developers mainly maintain API documents, however, it is often difficult for developers to independently and efficiently maintain a large number of API documents, and the API documents are maintained manually to sense API changes, so that problems cannot be timely and efficiently discovered, and thus, there is a hysteresis in processing the problems. In order to solve the problem of the hysteresis of the API change perceived by manual maintenance, the present application provides an API change monitoring method, which can automatically monitor the change event of the API, and includes the steps shown in fig. 1:

step 110: calling a target API, and performing syntax analysis on target API return data to obtain a data structure of the return data;

step 120: and determining whether the data structure of the returned data is consistent with a pre-stored data structure to monitor the change event of the target API, wherein the pre-stored data structure is determined based on the data structure of the called historical returned data of the target API.

The target API responds to the calling instruction and sends return data, the return data can reflect the bottom data of the target API, and when the target API is changed, the return data of the target API is changed accordingly. Therefore, whether the API is changed or not can be monitored by analyzing the return data of the target API. However, the information such as the specific value carried by the return data of the target API for each call may be different, that is, the return data of the target API in each call may not be identical even though the target API is not changed. The return data of the target API cannot be directly compared with the pre-stored data. The data structure of the returned data is related to the API underlying data, when the target API is changed, the data structure of the returned data is changed, and when the target API is not changed, the data structure of the returned data for each call is consistent. Therefore, the change event of the target API can be monitored by comparing whether the data structure of the returned data is consistent with the pre-stored data structure, the API document is not required to be maintained by manual intervention, and automatic monitoring of API change is realized. In some embodiments, the change event of the API may be periodically monitored, and by setting a timer, when the time set by the timer is reached, a call instruction is issued to the target API. The monitoring density of the API change can be set according to actual needs.

The data structure of the target API return data is obtained by parsing the return data, and in some embodiments, the abstract syntax tree may be used to perform lexical analysis on the target API return data to obtain the data structure of the return data. Abstract Syntax Trees (AST) are often used for the parsing of source programs and are Tree representations of the Abstract Syntax structure of the source code. The source code is converted into an abstract syntax tree without depending on concrete grammar and language details. The method and the device utilize the abstract syntax tree to perform lexical analysis on the returned data so as to obtain a data structure of the returned data. In some embodiments, the target API return data may be structured data, such as key-value structure data. The parsed data structure may include key attributes, value attributes, or hierarchical information of different keys. For example, when the target API is a weight recording function interface, after calling the target API, the return data of the response may be:

the return data in the above example is key-value structure data, and after lexical analysis is performed through the abstract syntax tree, the data structure of the return data, including key attributes, value attributes, or hierarchical information of different keys, can be obtained. For a statement "" id ":3," after lexical analysis through the abstract syntax tree, the data structure can be obtained:

the data structure obtained after the other statements in the returned data are lexically analyzed through the abstract syntax tree is similar to the above data structure, and the detailed description is omitted here. The data structure of the above example includes key attributes, value attributes, and hierarchy information for the keys. Whether the data structure of the returned data is consistent with the pre-stored data structure or not can be monitored, and whether the target API is changed or not can be monitored. In some embodiments, the pre-stored data structure may be determined based on a data structure of historical return data of the called target API, e.g., at least twice calling the target API, and storing the data structure of the historical data if the data structure of the historical data returned after each call is the same. The pre-stored data structure may be sorted by the steps shown in FIG. 2:

step 210: issuing an API;

step 220: calling an API;

if the call is passed, go to step 240; otherwise, step 230 is performed.

Step 230: returning error information;

step 240: when the API call is passed, the API responds to the call instruction and sends return data, lexical analysis is carried out on the API return data by using the abstract syntax tree, a data structure of the return data is obtained, and the data structure is cached;

step 250: judging whether the calling times of the API reach a threshold value or not;

for example, the threshold may be a value greater than 2, and step 260 is performed if the number of calls reaches the threshold, otherwise step 220 is returned.

Step 260: judging whether the data structures of the data returned for multiple times are consistent;

if yes, go to step 270, otherwise return to step 230.

Step 270: and carrying out persistent storage on the data structure.

In the library falling method of the data structure, step 210 may be understood as a trigger condition, and when an API is issued in the system, the issued API is automatically called. And acquiring and comparing data structures of returned data responded by the API called for many times, and if the data structures are consistent, performing persistent storage on the data structures. In the monitoring of the API change, a data structure stored persistently is used as a pre-stored data structure to be compared with a data structure of return data called immediately so as to monitor the change event of the API.

In some embodiments, after a change event of a target API is monitored, alarm information of a target API change may be sent to prompt a user to process the target API. Wherein, the alarm information can carry the change information of the target API. Specifically, after it is monitored that the target API changes, the stack where the error occurs may be analyzed, the error is organized according to the configured granularity, and then an error callback is executed, where the callback event may carry an error information stack to prompt a user to process the change event of the target API. The user can choose to ignore the change of the target API according to actual needs, and can also choose to update the pre-stored data structure to the data structure of the returned data of the changed target API.

According to the API change monitoring method, grammatical analysis is carried out on the returned data responded by the target API aiming at the call request, the data structure of the returned data is obtained, the data structure of the returned data is compared with the prestored data structure, whether the target API is changed or not is monitored, accordingly, the API document is not required to be maintained through manual intervention, and automatic monitoring of API change is achieved.

In addition, the present application also provides an API change monitoring method, including the steps shown in fig. 3:

step 311: issuing an API;

step 312: calling an API;

if the call is passed, go to step 314; otherwise, step 313 is performed.

Step 313: returning error information;

step 314: when the API call is passed, the API responds to the call instruction and sends return data, lexical analysis is carried out on the API return data by using the abstract syntax tree, a data structure of the return data is obtained, and the data structure is cached;

step 315: judging whether the calling times of the API reach a threshold value or not;

for example, the threshold may be a value greater than 2, and step 316 is performed if the number of calls reaches the threshold, otherwise step 312 is returned.

Step 316: judging whether the data structures of the data returned for multiple times are consistent;

if yes, go to step 317, otherwise return to step 313.

Step 317: and carrying out persistent storage on the data structure.

The steps 311-317 are database dropping steps of the data structure, and the specific implementation manner is as shown in the above embodiment of fig. 2, which is not described herein again.

After the data structure is subjected to the library falling, namely the data structure of the persistent storage is determined, the following steps are executed:

step 321: when the preset time is reached, calling the API;

if the call is passed, go to step 323; otherwise, step 322 is performed.

Step 322: returning error information;

step 323: when the API call is passed, the API responds to the call instruction and sends return data, and lexical analysis is carried out on the API return data by using the abstract syntax tree to obtain a data structure of the return data;

step 324: judging whether the data structure of the returned data is consistent with the data structure of the persistent storage;

if yes, go back to step 321, otherwise go to step 325.

Step 325: and sending alarm information of API change to prompt a user to process the API.

The steps 321-325 are API change monitoring steps, and the specific implementation manner refers to the above embodiments, which are not described herein again.

In some cases, the server provides an API service, and the client may obtain the server resource by calling the API service. For example, the server may provide an HTTP interface, i.e., an HTTP API. The HTTP API is composed of a URL for marking a server resource address and an HTTP method, which may include a GET, PUT, DELETE, etc. request header. When the resource structure or the type of the HTTP API of the server changes, a client developer cannot timely perceive the change of the HTTP API in the server, which may cause a series of problems such as delay in subsequent problem processing. Therefore, in some embodiments, an API change monitoring method provided by the present application may be applied to a client, where a target API is located at a server, and the method includes the steps as described in fig. 4:

step 410: the client 10 sends an instruction for calling a target API to the server 20;

step 420: the target API in the server 20 sends return data to the client 10 in response to the call instruction;

step 430: the client 10 utilizes the abstract syntax tree to perform lexical analysis on the target API return data to obtain a data structure of the return data;

step 440: the client terminal 10 determines whether the data structure of the returned data is consistent with a pre-stored data structure to monitor the change event of the target API.

For the specific implementation of the above steps, refer to the above embodiments, which are not described herein again.

By the API change monitoring method, the client can automatically monitor the change event of the API in the server, on one hand, the change of the API can be perceived in place of manual maintenance, and on the other hand, when the API in the server is changed, the client can monitor the change of the API in time.

Based on the API change monitoring method according to any of the embodiments, the present application further provides an API change monitoring system 500 shown in fig. 5, including a client 510 and a server 520, where the server 520 is loaded with at least one API;

the server 520 is configured to store the relevant data of the API, and return response data when receiving a call request from the client 510 to the target API;

the client 510 is configured to pre-store a data structure of historical return data of a called target API, send a request for calling the target API in the server 520, perform syntax analysis on response data returned by the target API, obtain a data structure of the return data, and determine whether the data structure of the return data is consistent with a pre-stored data structure, so as to monitor a change event of the target API in the server 520, where the pre-stored data structure is determined based on the data structure of the historical return data of the called target API.

Based on the API change monitoring method described in any of the embodiments above, the present application further provides a client 600 as shown in fig. 6, where the client 600 may be the client 510 in the API change monitoring system 500 as shown in fig. 5. The client 600 includes:

the analysis module 610 is configured to invoke a target API, perform syntax analysis on target API return data, and obtain a data structure of the return data;

a monitoring module 620, configured to determine whether a data structure of the returned data is consistent with a pre-stored data structure, so as to monitor a change event of the target API, where the pre-stored data structure is determined based on a data structure of the called historical returned data of the target API.

In some embodiments, the analysis module 610 is further configured to perform lexical analysis on the target API return data by using an abstract syntax tree, so as to obtain a data structure of the return data.

In some embodiments, the monitoring module 620 is further configured to call the target API at least twice, and store the data structure of the historical data if the data structure of the historical data returned after each call is the same.

In some embodiments, the client 600 further includes an alarm module 630 (not shown) for sending alarm information of the target API change to prompt a user to process the target API.

The implementation process of the functions and actions of each module in the above device is specifically described in the implementation process of the corresponding step in the above method, and is not described herein again.

Based on the API change monitoring method described in any of the above embodiments, the present application further provides a schematic structural diagram of an electronic device as shown in fig. 7. As shown in fig. 7, at the hardware level, the electronic device includes a processor, an internal bus, a network interface, a memory, and a non-volatile memory, and may also include hardware required for other services. The processor reads a corresponding computer program from the nonvolatile memory into the memory and then runs the computer program to implement the API change monitoring method according to any of the embodiments described above.

The foregoing description of specific embodiments of the present application has been presented. Other embodiments are within the scope of the following claims. In some cases, the actions or steps recited in the claims may be performed in a different order than in the embodiments and still achieve desirable results. In addition, the processes depicted in the accompanying figures do not necessarily require the particular order shown, or sequential order, to achieve desirable results. In some embodiments, multitasking and parallel processing may also be possible or may be advantageous.

Other embodiments of the present application will be apparent to those skilled in the art from consideration of the specification and practice of the invention disclosed herein. This application is intended to cover any variations, uses, or adaptations of the invention following, in general, the principles of the application and including such departures from the present disclosure as come within known or customary practice within the art to which the invention pertains. It is intended that the specification and examples be considered as exemplary only, with a true scope and spirit of the application being indicated by the following claims.

Claims

1. An API change monitoring method, the method comprising:

2. The method of claim 1, wherein the API change monitoring is periodic monitoring.

3. The method of claim 1, wherein the data structure of the return data is obtained by:

and carrying out lexical analysis on the target API return data by using an abstract syntax tree to obtain a data structure of the return data.

4. The method of claim 1, wherein the target API return data is structured data, and wherein the data structure comprises key attributes, value attributes, or hierarchical information of different keys.

5. The method of claim 1, wherein the pre-stored data structure is determined based on a data structure of historical return data of the called target API, and comprises:

and calling the target API at least twice, and storing the data structure of the historical data if the data structure of the historical data returned after each calling is the same.

6. The method of claim 1, wherein after monitoring the change event of the target API, further comprising the steps of:

and sending alarm information of the target API change to prompt a user to process the target API.

7. The method of claim 1, wherein the method is applied to a client and the target API is located on a server.

8. The API change monitoring system is characterized by comprising a client and a server, wherein the server is loaded with at least one API;

9. A client, the client comprising:

10. An electronic device, characterized in that the electronic device comprises:

a processor;

a memory for storing processor-executable instructions;

wherein the processor is configured to: