Method, system and equipment for generating change record of API (Application Program Interface) detailed table and medium

Abstract

The invention provides a method, a system and equipment for generating a change record of an API (Application Program Interface) detailed table and a medium, and relates to the technical field of electronic and electrical architecture and software development, and the method comprises the following steps: obtaining a first version API detailed table and a second version API detailed table; respectively carrying out data processing on the first version API detailed table and the second version API detailed table to obtain a first character string data set corresponding to the first version API detailed table and a second character string data set corresponding to the second version API detailed table; comparing the first character string data set with the second character string data set, and determining update content of the second version API detailed table relative to the first version API detailed table based on a comparison result; and generating a change record of the second version API detailed table relative to the first version API detailed table according to the update content. Automatic tracking and recording of API detailed table version updating are achieved, management and control personnel are assisted in managing and controlling the API detailed table with higher quality, and then the data transmission quality and the network development efficiency are improved.

Description

Technical Field

[0001] This application relates to the fields of electronic and electrical architecture and software development technology, and in particular to a method, system, device and medium for generating change records of API details. Background Technology

[0002] In recent years, with the development of intelligent electric vehicles, the vehicle's electronic and electrical architecture is evolving from a distributed model to a centralized domain architecture and a central gateway architecture. This centralization of functions has led to higher data transmission rates and bandwidth requirements, promoting the application of in-vehicle Ethernet and service-oriented architectures. Among these, service-oriented architecture, through standardized interfaces, loosely coupled mechanisms, and good scalability, combined with high-performance domain controllers, has become a crucial foundation for "software-defined vehicles."

[0003] Under this architecture, the vehicle development process changes. Service interfaces need to be defined in advance and compiled into API (Application Programming Interface) details, which are then handed over to the web development team to generate ARXML and other files for software development. Since the entire vehicle involves a large number of functional modules and service combinations, resulting in a huge number of interfaces, the quality of API detail management directly affects development efficiency and system consistency.

[0004] However, in actual development, minor changes in the API details table may cause script conflicts or interface inconsistencies, and the ARXML file modification process is complex and can easily delay development.

[0005] Therefore, there is an urgent need for a method that can effectively record changes in API details to improve the quality of interface management and ensure the efficiency and stability of vehicle development. Summary of the Invention

[0006] In view of the above problems, embodiments of this application provide a method, system, device and medium for generating change records of API details, so as to overcome the above problems or at least partially solve the above problems.

[0007] In a first aspect, this application provides a method for generating change records of an API detail table, the method comprising: Obtain the first version API detailed table and the second version API detailed table. The second version API detailed table is obtained after updating the first version API detailed table. Data processing is performed on the first version API detail table and the second version API detail table respectively to obtain the first string dataset corresponding to the first version API detail table and the second string dataset corresponding to the second version API detail table. Compare the first string dataset with the second string dataset, and based on the comparison results, determine the updated content of the second version API detail table relative to the first version API detail table; Based on the updated content, a change record of the second version API details table relative to the first version API details table is generated.

[0008] Optionally, data processing is performed on the first version API detail table and the second version API detail table respectively to obtain a first string dataset corresponding to the first version API detail table and a second string dataset corresponding to the second version API detail table, including: Obtain the type of each data table page in the API detail table, wherein the API detail table is either the first version API detail table or the second version API detail table; Based on the type of the data table page, and according to the unique identification rules preset for the type of the data table page, the data in the data table page is processed to obtain the mapping relationship between the unique identifier and the corresponding attribute identifier in the data table page. The attribute identifier includes multiple attribute data. Based on the mapping relationship between the unique identifiers and corresponding attribute identifiers in each data page of the API detail table, the string dataset corresponding to the API detail table is determined, and the string dataset is either the first string dataset or the second string dataset.

[0009] Optionally, determining the string dataset corresponding to the API detail table based on the mapping relationship between unique identifiers and corresponding attribute identifiers in each data page of the API detail table includes: Use the unique identifier in the data table page as the primary index item; The attribute identifier corresponding to the unique identifier is used as the associated field name of the main index item; The multiple attribute data associated with the attribute identifier are used as multiple data fields associated with the associated field name, wherein each data field corresponds to a data field name, and the data field name is determined based on the mapping relationship between the keyword element in the data field and the column coordinate of the data field. The main index item, the associated field name corresponding to the main index item, and the multiple data fields associated with the associated field name are concatenated to obtain the string dataset corresponding to the API detail table.

[0010] Optionally, comparing the first string dataset with the second string dataset includes: Iterate through the first unique identifier in the first string dataset, and query whether there is a second unique identifier in the second string dataset. If no second unique identifier corresponding to the first unique identifier is found in the second string dataset, determine that the second version API detail table has undergone a deletion-type change relative to the first version API detail table, and record the corresponding deleted data fields. The first unique identifier corresponds to the second unique identifier. Iterate through the second unique identifier in the second string dataset, and query whether the first unique identifier exists in the first string dataset. If no first unique identifier corresponding to the second unique identifier is found in the first string dataset, determine that the second version of the API details table has a new class change relative to the first version of the API details table, and record the corresponding new data field.

[0011] Optionally, if a second unique identifier corresponding to the first unique identifier is found in the second string dataset, or if a first unique identifier corresponding to the second unique identifier is found in the first string dataset, the method further includes: Obtain the first target data field under the target associated field name of the first unique identifier, and the second target data field under the same target associated field name of the second unique identifier. The target associated field name is either the first unique identifier or the second unique identifier, and the first target data field and the second target data field correspond to each other. Based on preset delimiter rules, the first target data field is parsed into a first data sequence, and the second target data field is parsed into a second data sequence; The first data sequence and the second data sequence are compared item by item, and the data items that differ from each other, as well as the associated field name and data field name of the data items that differ from each other, are recorded.

[0012] Optionally, based on the updated content, a change record of the second version API detail table relative to the first version API detail table is generated, including: Based on the updated content, the data table pages are categorized according to their types to obtain the updated content corresponding to each data table page. Based on the update content corresponding to each of the data table pages, the updates are categorized by type, and different types of update content are displayed in their respective label areas to generate a change record of the second version API detail table relative to the first version API detail table.

[0013] Optionally, before processing the data in the first version API detail table and the second version API detail table, the method further includes: The format of the data table pages in the API details table is checked for validity. The API details table is either the first version of the API details table or the second version of the API details table. If the format of a data page in the API details table is found to be invalid, the data processing for the API details table will be terminated and a prompt message will be output. If the format of the data page in the API details table is found to be valid, the column coordinate information of each attribute data in the data page is recorded, and a mapping relationship is established between the keyword element of each attribute data and the corresponding column coordinate information.

[0014] A second aspect of this application provides a system for generating change records for API detail tables, the system comprising: The acquisition module is used to acquire the first version API detail table and the second version API detail table, wherein the second version API detail table is obtained after the first version API detail table is updated. The data processing module is used to process the first version API detail table and the second version API detail table respectively to obtain the first string dataset corresponding to the first version API detail table and the second string dataset corresponding to the second version API detail table. The data comparison module is used to compare the first string dataset with the second string dataset, and based on the comparison results, determine the updated content of the second version API details table relative to the first version API details table; The generation module is used to generate a change record of the second version API detail table relative to the first version API detail table based on the updated content.

[0015] Optionally, data processing is performed on the first version API detail table and the second version API detail table respectively to obtain a first string dataset corresponding to the first version API detail table and a second string dataset corresponding to the second version API detail table. The data processing module includes: The first acquisition submodule is used to acquire the type of each data table page of the API detail table, wherein the API detail table is either the first version API detail table or the second version API detail table; The data processing submodule is used to process the data in the data table page according to the type of the data table page and according to the unique identification rules preset for the type of the data table page, so as to obtain the mapping relationship between the unique identifier and the corresponding attribute identifier in the data table page, wherein the attribute identifier includes multiple attribute data; The first determining submodule is used to determine the string dataset corresponding to the API detailed table based on the mapping relationship between the unique identifier and the corresponding attribute identifier in each data table page of the API detailed table, wherein the string dataset is either the first string dataset or the second string dataset.

[0016] Optionally, the first determining submodule, which determines the string dataset corresponding to the API detail table based on the mapping relationship between unique identifiers and corresponding attribute identifiers in each data page of the API detail table, includes: The first determining subunit is used to use the unique identifier in the data table page as the primary index item; The second determining subunit is used to use the attribute identifier corresponding to the unique identifier as the associated field name of the main index item; The third determining subunit is used to treat the multiple attribute data associated with the attribute identifier as multiple data fields associated with the associated field name, wherein each data field corresponds to a data field name, and the data field name is determined based on the mapping relationship between the keyword element in the data field and the column coordinate of the data field. The concatenation subunit is used to concatenate the main index item, the associated field name corresponding to the main index item, and multiple data fields associated with the associated field name to obtain the string dataset corresponding to the API detail table.

[0017] Optionally, the data comparison module for comparing the first string dataset with the second string dataset includes: The first traversal and query submodule is used to traverse the first unique identifier in the first string dataset, query whether there is a second unique identifier in the second string dataset, and if no second unique identifier corresponding to the first unique identifier is found in the second string dataset, it is determined that the second version API detailed table has undergone a deletion-type change relative to the first version API detailed table, and the corresponding deleted data fields are recorded. The first unique identifier corresponds to the second unique identifier. The second traversal and query submodule is used to traverse the second unique identifier in the second string dataset, query whether the first unique identifier exists in the first string dataset, and if no first unique identifier corresponding to the second unique identifier is found in the first string dataset, it is determined that the second version API details table has a new class change relative to the first version API details table, and the corresponding new data field is recorded.

[0018] Optionally, the system further includes: The second acquisition submodule is used to acquire the first target data field under the target associated field name of the first unique identifier, and the second target data field under the same target associated field name of the second unique identifier. The target associated field name is either the first unique identifier or the second unique identifier, and the first target data field and the second target data field correspond to each other. The data parsing submodule is used to parse the first target data field into a first data sequence and the second target data field into a second data sequence based on preset delimiter rules. The first data sequence and the second data sequence are compared item by item, and the data items that differ from each other, as well as the associated field name and data field name of the data items that differ from each other, are recorded.

[0019] Optionally, based on the updated content, a change record of the second version API detail table relative to the first version API detail table is generated. The generation module includes: The first classification submodule is used to classify the updated content according to the type of the data table page to obtain the updated content corresponding to each of the data table pages. The second classification submodule is used to classify the update content of each data table page according to the update type, and display the update content of different types in their respective label areas to generate the change record of the second version API detail table relative to the first version API detail table.

[0020] Optionally, the system further includes: The detection submodule is used to detect the format validity of the data table pages in the API details table, wherein the API details table is either the first version API details table or the second version API details table; The information prompt submodule is used to terminate data processing for the API details table and output a prompt message when the format of the data page in the API details table is found to be invalid. The recording submodule is used to record the column coordinate information of each attribute data in the data table page when the format of the data table page in the API details table is detected to be valid, and to establish a mapping relationship between the keyword element of each attribute data and the corresponding column coordinate information.

[0021] A third aspect of this application provides an electronic device, including a memory, a processor, and a program or instructions stored in the memory and executable on the processor, wherein the program or instructions, when executed by the processor, implement the steps of the method for generating change records of API detail tables as described in the first aspect of this application.

[0022] A fourth aspect of this application provides a readable storage medium storing a program or instructions that, when executed by a processor, implement the steps of the method for generating change records of the API detail table as described in the first aspect of this application.

[0023] The beneficial effects of this application are: This application proposes a method for generating change records for API detail tables. First, a first version and a second version of the API detail table are obtained, where the second version is an update of the first version. Second, data processing is performed on both versions to obtain a first string dataset corresponding to the first version and a second string dataset corresponding to the second version. Then, the first and second string datasets are compared, and based on the comparison results, the updated content of the second version relative to the first version is determined. Finally, a change record for the second version relative to the first version is generated based on the updated content. This application achieves automated tracking and recording of API detail table version updates by obtaining two versions of the API detail table, converting their contents into string datasets, comparing them, and generating change records based on the comparison results. This assists management personnel in managing API detail tables more effectively, thereby improving data transmission quality and network development efficiency. Attached Figure Description

[0024] To more clearly illustrate the technical solutions of the embodiments of this application, the drawings used in the description of the embodiments of this application will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0025] Figure 1 This is a flowchart illustrating the steps of a method for generating change records for an API detail table, as provided in an embodiment of this application. Figure 2 This is a schematic diagram illustrating the output representation of a change record provided in an embodiment of this application; Figure 3 This is a flowchart illustrating an API detail table change identification method provided in an embodiment of this application. Figure 4 This is a schematic diagram of a system for generating change records of API detail tables provided in an embodiment of this application; Figure 5 This is a schematic diagram of an electronic device provided in an embodiment of this application. Detailed Implementation

[0026] Exemplary embodiments of this application will now be described in more detail with reference to the accompanying drawings. While exemplary embodiments of this application are shown in the drawings, it should be understood that this application may be implemented in various forms and should not be limited to the embodiments set forth herein. Rather, these embodiments are provided to enable a more thorough understanding of this application and to fully convey the scope of this application to those skilled in the art.

[0027] In a first aspect, this application provides a method for generating change records for an API detail table, such as... Figure 1 As shown, the method includes: Step S101: Obtain the first version API detail table and the second version API detail table, wherein the second version API detail table is obtained after updating the first version API detail table.

[0028] In this step, two different versions of the API detail table file are first loaded and identified, and labeled as the first version API detail table and the second version API detail table respectively. In some cases, the second version API detail table is the latest version API detail table formed by changing information based on the first version API detail table.

[0029] Step S102: Perform data processing on the first version API detail table and the second version API detail table respectively to obtain the first string dataset corresponding to the first version API detail table and the second string dataset corresponding to the second version API detail table.

[0030] In this step, unified data processing operations are performed on both the first and second version API detail tables. The aim is to transform the structured tabular data into a standardized string dataset suitable for subsequent comparative analysis. In some cases, this data processing may involve parsing various data sheets within the API detail tables, extracting key field information, and organizing the data related to each service or event into a continuous string format according to a predetermined field order and format requirements. To ensure clear and distinguishable boundaries between fields, specific delimiters (such as "@@") are typically inserted between fields to form uniquely identified data records. In this way, a first string dataset corresponding to the first version API detail table and a second string dataset corresponding to the second version API detail table are generated, providing a unified data foundation and convenient processing method for subsequent data comparison and change identification. The core of this step lies in achieving a linear expression of complex structured data through stringification, improving processing efficiency and identification accuracy.

[0031] Step S103: Compare the first string dataset with the second string dataset, and based on the comparison result, determine the updated content of the second version API detail table relative to the first version API detail table.

[0032] In this step, the first string dataset and the second string dataset are compared item by item to identify the specific updates made in the second version of the API details table compared to the first version. The comparison process is based on the unique identifier of each string data record, searching for differences between the strings corresponding to the same identifier items in the two versions, and thus determining whether the item has been modified.

[0033] Step S104: Based on the updated content, generate a change record of the second version API detail table relative to the first version API detail table.

[0034] In this step, based on the updated content identified in step S103, a complete change record of the second version API detail table relative to the first version API detail table is automatically generated. In some cases, detailed information of different change types will be organized according to preset rules or formats, and the change content will be output in a structured manner.

[0035] This application obtains two versions of API detail tables, converts their contents into string datasets for comparison, and generates change records based on the comparison results. This enables automated tracking and recording of API detail table version updates, assisting management personnel in managing API detail tables with higher quality, thereby improving data transmission quality and network development efficiency.

[0036] In one embodiment, data processing is performed on the first version API detail table and the second version API detail table respectively to obtain a first string dataset corresponding to the first version API detail table and a second string dataset corresponding to the second version API detail table, including: Obtain the type of each data table page in the API detail table, wherein the API detail table is either the first version API detail table or the second version API detail table; Based on the type of the data table page, and according to the unique identification rules preset for that data table page type, the data in the data table page is processed to obtain the mapping relationship between the unique identifier and the corresponding attribute identifier in the data table page. The attribute identifier includes multiple attribute data. Based on the mapping relationship between the unique identifier and the corresponding attribute identifier in each data table page of the API detailed table, the string dataset corresponding to the API detailed table is determined. The string dataset is either the first string dataset or the second string dataset.

[0037] In this embodiment, to achieve structured comparison and efficient change identification of the API detailed table, standardized data processing is performed on the first and second versions of the API detailed table to construct their respective string datasets. This processing includes the following steps: First, the types of multiple data sheets contained in the API detailed table are identified, such as service signal definition tables, data type definition tables, and communication behavior definition tables. Then, for each data sheet type, the data in the table is extracted in a structured manner according to a preset unique identifier rule, and a mapping relationship is generated between a unique identifier and its corresponding set of attribute identifiers (such as field names and field values). Next, the attribute identifiers in each mapping relationship are concatenated into strings of a uniform format and organized according to the unique identifiers to form a complete dataset. Finally, the processed results of all data sheets in the API detailed table are integrated into a unified string dataset, serving as the basis for subsequent comparative analysis, forming the first string dataset and the second string dataset. This method not only ensures the integrity and consistency of the API detailed table structure but also improves the accuracy and processing efficiency of change identification.

[0038] In one embodiment, determining the string dataset corresponding to the API detail table based on the mapping relationship between unique identifiers and corresponding attribute identifiers in each data page of the API detail table includes: Use the unique identifier in the data table page as the primary index item; The attribute identifier corresponding to the unique identifier is used as the associated field name of the main index item; The multiple attribute data associated with the attribute identifier are used as multiple data fields associated with the associated field name, wherein each data field corresponds to a data field name, and the data field name is determined based on the mapping relationship between the keyword element in the data field and the column coordinate of the data field. The main index item, the associated field name corresponding to the main index item, and the multiple data fields associated with the associated field name are concatenated to obtain the string dataset corresponding to the API detail table.

[0039] In this embodiment, to construct the string dataset corresponding to the API detail table, it is necessary to perform the following steps based on the mapping relationship between unique identifiers and corresponding attribute identifiers in each data table page: First, the unique identifiers in the data table pages are used as the main index item to uniquely identify each service, data type, or communication behavior record; then, all attribute identifiers associated with the main index item are extracted and used as the associated field names under the main index item; next, the actual data values ​​are obtained from each column corresponding to the attribute identifiers to form multiple data fields, and the field name of each data field is determined by combining the column coordinates of the field content and the mapping relationship between keyword elements to ensure the accuracy and traceability of the data field definition; finally, the main index item, all corresponding associated field names, and the specific data fields under each field name are sequentially concatenated according to a preset order and delimiter to form a structured and unique string representation, ultimately constituting the complete API detail table string dataset. This dataset serves as the basis for subsequent difference comparison and change identification, greatly improving processing efficiency and automation operability while ensuring information integrity.

[0040] For example, this application uses a service-type data page table as an example to illustrate that after hashing the data in the service-type data page, the resulting string dataset is: <Service ID1, Event ID1@@Data Field1@@Data Field2@@Data Field3@@Event ID2@@Data Field1@@Data Field2@@Data Field3@@…>; <Service ID2, Event ID1@@Data Field1@@Data Field2@@Data Field3@@Time ID2@@Data Field1@@Data Field2@@Data Field3@@…>, where different data fields are separated by a preset delimiter, which can be a custom delimiter, such as the character "@@" which is never used in API detail tables.

[0041] In one embodiment, the data page types include service-type data page, data-type data page, and communication behavior-type data page. The step of processing the data in the data page according to its type and a preset unique identifier rule includes: According to the pre-defined rule that service IDs are unique for the service type data page, the data in the service type data page is hashed; or, According to the pre-defined rule that data names are unique for the data type of data table page, the data in the data type of data table page is hashed; or, According to the pre-defined rule that the Ethernet node IP and instance ID are unique for the communication behavior data table page, the data in the communication behavior data table page is hashed. The unique identifier for the service-type data table page is the service ID, and the attribute identifier is the time ID. The unique identifier for the data-type data table page is the data name, and the attribute identifier is the member variable name. The unique identifier for the communication behavior-type data table page is the terminating node IP and the instance ID, and the attribute identifier is the client IP. Obtaining the mapping relationship between the unique identifiers and corresponding attribute identifiers in the data table page includes: Based on the hashing result of the data in the service-type data table page, the mapping relationship between the service ID and the event ID is obtained; or, Based on the hashing result of the data in the data table page of the data class, the mapping relationship between the data name and the member variable name is obtained; or, Based on the hashing result of the data in the communication behavior data table, the mapping relationship between the Ethernet node IP and the example ID and the client IP is obtained.

[0042] In this embodiment, the data page types include three types: service-type data page, data-type data page, and communication behavior-type data page.

[0043] The service-type data table primarily defines the basic information of each service and its included methods or events. This embodiment processes the data in this table according to the rule of "unique service ID," using each service ID as a unique identifier; its subordinate event IDs as attribute identifiers; and the description, type, port information, etc., of each method or event as attribute data. Based on the hash processing, a mapping relationship is generated between service IDs and their corresponding event IDs, establishing a clear data structure for the service hierarchy.

[0044] The data table records the data type structures used in each service call, including composite data, structures, arrays, etc. This embodiment processes data according to the rule of "unique data name," using the data name as a unique identifier; and using the names of its subordinate member variables as attribute identifiers, extracting and recording attribute fields such as type, length, and initial value. Through hash processing, a mapping relationship is established between the data name and multiple member variable names, achieving an ordered description of the data structure hierarchy.

[0045] The communication behavior data table defines the behavioral configuration of the service communication between the client and the server, such as IP address, port, instance ID, etc. This embodiment follows the rule of "unique service ID + instance ID," using the combination of these two as a unique identifier. The client IP is used as the attribute identifier to further record key parameters involved in the service, such as client IP, service port, and communication protocol. Through hashing, a mapping relationship is established between the service ID + instance ID and the client IP, accurately reflecting the configuration structure of cross-domain communication.

[0046] In this embodiment, by constructing a mapping relationship between unique identifiers and attribute identifiers, not only is the logicality and consistency of data organization improved, but an accurate basic index is also provided for subsequent generation of string datasets and rapid location of differing fields. During the comparison phase, efficient change identification at multiple levels can be achieved by relying on the string data structure, thereby enhancing the accuracy and robustness of the entire API detailed table version management and significantly improving the ability to handle complex interface changes.

[0047] Table 1 below shows an API detail table provided in this application. This API detail table includes at least the following types of data table pages: service data table pages, data data table pages, and communication behavior data table pages. See Table 1 for details:

[0048] Table 1 In one embodiment, comparing the first string dataset with the second string dataset includes: Iterate through the first unique identifier in the first string dataset, and query whether there is a second unique identifier in the second string dataset. If no second unique identifier corresponding to the first unique identifier is found in the second string dataset, determine that the second version API detail table has undergone a deletion-type change relative to the first version API detail table, and record the corresponding deleted data fields. The first unique identifier corresponds to the second unique identifier. Iterate through the second unique identifier in the second string dataset, and query whether the first unique identifier exists in the first string dataset. If no first unique identifier corresponding to the second unique identifier is found in the first string dataset, determine that the second version of the API details table has a new class change relative to the first version of the API details table, and record the corresponding new data field.

[0049] In this embodiment, the process of comparing the first string dataset and the second string dataset includes bidirectional traversal and matching operations, aiming to identify additions and deletions between API detail table versions. Specifically, firstly, each first unique identifier in the first string dataset is traversed, and a corresponding second unique identifier is searched in the second string dataset. If no corresponding item is found, it is determined that the second version of the API detail table has undergone a deletion-type change compared to the first version, that is, the service or data structure has been deleted, and the relevant field content is recorded as deleted data fields. Subsequently, each second unique identifier in the second string dataset is traversed in reverse, and a matching first unique identifier is searched in the first string dataset. If no match is found, it is determined that the second version of the API detail table has added this data, which is a addition-type change, and all field information of the added data field is recorded.

[0050] This embodiment, through the aforementioned bidirectional comparison strategy, can comprehensively cover structural changes in the API details table, achieving accurate identification and systematic recording of additions and deletions.

[0051] In one embodiment, when a second unique identifier corresponding to a first unique identifier is found from the second string dataset, or when a first unique identifier corresponding to a second unique identifier is found from the first string dataset, the method further includes: Obtain the first target data field under the target associated field name of the first unique identifier, and the second target data field under the same target associated field name of the second unique identifier. The target associated field name is either the first unique identifier or the second unique identifier, and the first target data field and the second target data field correspond to each other. Based on preset delimiter rules, the first target data field is parsed into a first data sequence, and the second target data field is parsed into a second data sequence; The first data sequence and the second data sequence are compared item by item, and the data items that differ from each other, as well as the associated field name and data field name of the data items that differ from each other, are recorded.

[0052] In this embodiment, when a matching unique identifier is found in two string datasets (i.e., the first unique identifier and the second unique identifier correspond to each other), a field-level deep comparison operation needs to be performed to identify whether there are any changes in the specific content of the attribute fields under the corresponding unique identifiers.

[0053] Specifically, firstly, in the data structures corresponding to the unique identifiers, the first target data field and the second target data field corresponding to a certain target associated field name are located and extracted. The first target data field comes from the first unique identifier, and the second target data field comes from the second unique identifier.

[0054] Subsequently, based on preset delimiter rules (such as "@@"), each target data field is parsed and split into an ordered data sequence, namely the first data sequence and the second data sequence, with each element corresponding to the value of a specific data field.

[0055] Furthermore, the two data sequences are compared item by item to identify any inconsistent field values. When a difference is found, the associated field name and data field name corresponding to the difference are recorded. In this embodiment, the data field name is mapped from column coordinates to field keyword elements. The mapping relationship between column coordinates and field keyword elements is pre-established by checking the format validity of the data page in the API details table.

[0056] This embodiment can not only accurately locate subtle differences at the field level, but also provide detailed basis for the subsequent classification and output of change records. Through this implementation method, in addition to identifying structural changes (such as additions / deletions), it can further capture fine-grained changes at the field content level, comprehensively improving the accuracy and completeness of API detail table version difference identification, and providing strong data support for downstream development, testing, and documentation updates.

[0057] In one embodiment, based on the updated content, generating a change record of the second version API detail table relative to the first version API detail table includes: Based on the updated content, the data table pages are categorized according to their types to obtain the updated content corresponding to each data table page. Based on the update content corresponding to each of the data table pages, the updates are categorized by type, and different types of update content are displayed in their respective label areas to generate a change record of the second version API detail table relative to the first version API detail table.

[0058] In this embodiment, refer to Figure 2 The diagram illustrates an output representation of a change log. After obtaining the updates from the second version of the API details table relative to the first version, to improve the clarity and readability of the change log, the updated content is further structured, categorized, and visualized, thus forming a complete change log. This process includes: First, based on the data sources involved in the updates, the data is initially categorized according to the type of data table page. Specifically, changes to service-related, data-related, and communication-related data table pages are divided into their respective independent categories. Each type of data table page has specific semantic characteristics and field formats; therefore, categorization improves the logic and professionalism of subsequent change display.

[0059] Subsequently, within each data table page, the updated content is further categorized according to the specific update type, including additions, deletions, and field modifications. For example, the service definition page may contain additions or deletions of services, or adjustments to event fields; the data type definition page may contain expansions of data structures or updates to member variable values; and the communication behavior page may involve changes to IP configurations or port parameters. Each type of update content is then assigned to a corresponding tag area or information block, and displayed in the final change log using columns, groups, or segments to form a well-structured and logically clear update report.

[0060] The change logs generated in this way not only fully cover all update points in various API detail tables, but also clearly present the type, location, and content of each change. This greatly facilitates developers, testers, reviewers, and other relevant personnel in quickly locating and understanding interface changes, improving the efficiency and professionalism of API version management. This method is particularly suitable for practical application scenarios such as version review, automated documentation generation, and development change notifications.

[0061] In one embodiment, before processing the data in the first version API detail table and the second version API detail table, the method further includes: The format of the data table pages in the API details table is checked for validity. The API details table is either the first version of the API details table or the second version of the API details table. If the format of a data page in the API details table is found to be invalid, the data processing for the API details table will be terminated and a prompt message will be output. If the format of the data page in the API details table is found to be valid, the column coordinate information of each attribute data in the data page is recorded, and a mapping relationship is established between the keyword element of each attribute data and the corresponding column coordinate information.

[0062] In this embodiment, to ensure the accuracy of subsequent data processing and the stability of system operation, a data table format validity check must first be performed before formal data processing is carried out on the first and second version API detail tables. This check verifies the structural integrity and field standardization of each sheet page in the API detail table, including checking for missing key fields, whether field names are standardized, whether duplicate unique identifiers exist, and whether the field order meets expectations.

[0063] When an invalid data table page format is detected in a certain API detail table (e.g., duplicate service ID, missing necessary fields, inconsistent field names, misaligned data columns, etc.), the processing flow of that API detail table will be immediately stopped, and a clear error message will be output to the user or operator, indicating the specific location or field of the error, to prevent invalid data from entering subsequent processing stages and causing comparison errors or system anomalies.

[0064] If the detection result shows that the API detail table format is valid, then continue the processing flow described above and perform the field coordinate recording operation: for each attribute field in the data table page, record its column coordinate information in the table (such as the index or letter number of the column), and further establish the mapping relationship between the keyword element of each attribute field and its column coordinate.

[0065] This embodiment introduces a format validity check and field mapping mechanism before formal data processing. This not only effectively avoids data anomalies or logical confusion caused by format errors, but also provides stable and reliable metadata support for the entire data processing process. This makes subsequent hash processing, string concatenation, and field-level comparison operations more accurate, efficient, and controllable, thereby comprehensively improving the accuracy and reliability of API detail table version change identification.

[0066] In one embodiment, this application provides a method such as Figure 3 The flowchart for API detail table change identification is shown in the figure: Step S31: First, it is necessary to obtain two versions of the API details table, namely the first version API details table and the second version API details table. It can be understood that the second version API details table is updated based on the first version API details table. The goal is to identify the differences between the two and proceed to step S32.

[0067] Step S32: Identify and process the two different versions of the API details table, extract the structural information and key fields, confirm the validity of the table content, and prepare for subsequent operations. Proceed to step S33.

[0068] Step S33, Data processing to generate hash data structure: The API details of the two versions are processed (hash processing) to construct the structured first string dataset and the second string dataset respectively, and then proceed to step S34.

[0069] Step S34: Data comparison and change identification: addition, deletion, or content change. If it is a content change, proceed to step S35; if it is an addition or deletion change, proceed to step S36.

[0070] Step S35: Deconstruct data fields, identify content changes, and proceed to S36.

[0071] Step S36: Organize the identified new class changes, deleted class changes, and content changes into a unified structure, output them in a structured manner, and form a complete API detail table change record, then proceed to step S37.

[0072] Step S37: Finally, the change record is visualized or exported for review, version control or development collaboration, improving the transparency and efficiency of the entire API interface management.

[0073] In this embodiment, by performing format validation, data processing, hash comparison, and change classification on two versions of API detail tables, it can efficiently and accurately identify new additions, deletions, and content changes in the API detail tables, automatically generate structured change records, and support visual display. This not only improves the accuracy and efficiency of interface change identification but also enhances the standardization and traceability of API detail table version management, providing strong support for interface control and development collaboration under the vehicle SOA architecture.

[0074] Based on the same inventive concept, a second aspect of the embodiments of this application provides a system for generating change records of API detail tables, such as... Figure 4 As shown, the system includes: The acquisition module 201 is used to acquire the first version API detail table and the second version API detail table, wherein the second version API detail table is obtained after the first version API detail table is updated. Data processing module 202 is used to process the first version API detail table and the second version API detail table respectively to obtain a first string dataset corresponding to the first version API detail table and a second string dataset corresponding to the second version API detail table. The data comparison module 203 is used to compare the first string dataset with the second string dataset, and based on the comparison result, determine the updated content of the second version API details table relative to the first version API details table; The generation module 204 is used to generate a change record of the second version API detail table relative to the first version API detail table based on the updated content.

[0075] Optionally, data processing is performed on the first version API detail table and the second version API detail table respectively to obtain a first string dataset corresponding to the first version API detail table and a second string dataset corresponding to the second version API detail table. The data processing module 202 includes: The first acquisition submodule is used to acquire the type of each data table page of the API detail table, wherein the API detail table is either the first version API detail table or the second version API detail table; The data processing submodule is used to process the data in the data table page according to the type of the data table page and according to the unique identification rules preset for the type of the data table page, so as to obtain the mapping relationship between the unique identifier and the corresponding attribute identifier in the data table page, wherein the attribute identifier includes multiple attribute data; The first determining submodule is used to determine the string dataset corresponding to the API detailed table based on the mapping relationship between the unique identifier and the corresponding attribute identifier in each data table page of the API detailed table, wherein the string dataset is either the first string dataset or the second string dataset.

[0076] Optionally, the first determining submodule, which determines the string dataset corresponding to the API detail table based on the mapping relationship between unique identifiers and corresponding attribute identifiers in each data page of the API detail table, includes: The first determining subunit is used to use the unique identifier in the data table page as the primary index item; The second determining subunit is used to use the attribute identifier corresponding to the unique identifier as the associated field name of the main index item; The third determining subunit is used to treat the multiple attribute data associated with the attribute identifier as multiple data fields associated with the associated field name, wherein each data field corresponds to a data field name, and the data field name is determined based on the mapping relationship between the keyword element in the data field and the column coordinate of the data field. The concatenation subunit is used to concatenate the main index item, the associated field name corresponding to the main index item, and multiple data fields associated with the associated field name to obtain the string dataset corresponding to the API detail table.

[0077] Optionally, the data comparison module 203, which compares the first string dataset with the second string dataset, includes: The first traversal and query submodule is used to traverse the first unique identifier in the first string dataset, query whether there is a second unique identifier in the second string dataset, and if no second unique identifier corresponding to the first unique identifier is found in the second string dataset, it is determined that the second version API detailed table has undergone a deletion-type change relative to the first version API detailed table, and the corresponding deleted data fields are recorded. The first unique identifier corresponds to the second unique identifier. The second traversal and query submodule is used to traverse the second unique identifier in the second string dataset, query whether the first unique identifier exists in the first string dataset, and if no first unique identifier corresponding to the second unique identifier is found in the first string dataset, it is determined that the second version API details table has a new class change relative to the first version API details table, and the corresponding new data field is recorded.

[0078] Optionally, the system further includes: The second acquisition submodule is used to acquire the first target data field under the target associated field name of the first unique identifier, and the second target data field under the same target associated field name of the second unique identifier. The target associated field name is either the first unique identifier or the second unique identifier, and the first target data field and the second target data field correspond to each other. The data parsing submodule is used to parse the first target data field into a first data sequence and the second target data field into a second data sequence based on preset delimiter rules. The first data sequence and the second data sequence are compared item by item, and the data items that differ from each other, as well as the associated field name and data field name of the data items that differ from each other, are recorded.

[0079] Optionally, based on the updated content, a change record of the second version API detail table relative to the first version API detail table is generated. The generation module 204 includes: The first classification submodule is used to classify the updated content according to the type of the data table page to obtain the updated content corresponding to each of the data table pages. The second classification submodule is used to classify the update content of each data table page according to the update type, and display the update content of different types in their respective label areas to generate the change record of the second version API detail table relative to the first version API detail table.

[0080] Optionally, the system further includes: The detection submodule is used to detect the format validity of the data table pages in the API details table, wherein the API details table is either the first version API details table or the second version API details table; The information prompt submodule is used to terminate data processing for the API details table and output a prompt message when the format of the data page in the API details table is found to be invalid. The recording submodule is used to record the column coordinate information of each attribute data in the data table page when the format of the data table page in the API details table is detected to be valid, and to establish a mapping relationship between the keyword element of each attribute data and the corresponding column coordinate information.

[0081] Based on the same inventive concept, a third aspect of the embodiments of this application provides a method as follows: Figure 5 The illustrated electronic device 100 includes a memory 110, a processor 120, and a program or instructions stored in the memory 110 and executable on the processor 120. When the program or instructions are executed by the processor 120, they implement the steps of the method for generating change records of API details as described in the first aspect of this application.

[0082] Based on the same inventive concept, a fourth aspect of the present application provides a readable storage medium storing a program or instructions, which, when executed by a processor, implements the steps of the method for generating change records of API detail tables as described in the first aspect of the present application.

[0083] Each embodiment in this specification focuses on the differences from other embodiments. For the same or similar parts between the embodiments, please refer to each other.

[0084] Those skilled in the art will understand that embodiments of this application can be provided as methods, apparatus, or computer program products. Therefore, embodiments of this application can take the form of entirely hardware embodiments, entirely software embodiments, or embodiments combining software and hardware aspects. Furthermore, embodiments of this application can take the form of computer program products implemented on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0085] This application describes embodiments with reference to flowchart illustrations and / or block diagrams of methods, terminal devices (systems), and computer program products according to embodiments of this application. It should be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing terminal device to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing terminal device, generate instructions for implementing the flowchart illustrations. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0086] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing terminal device to operate in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0087] These computer program instructions can also be loaded onto a computer or other programmable data processing terminal equipment, causing a series of operational steps to be performed on the computer or other programmable terminal equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable terminal equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0088] Although preferred embodiments of the present application have been described, those skilled in the art, upon learning the basic inventive concept, can make other changes and modifications to these embodiments. Therefore, the appended claims are intended to be interpreted as including the preferred embodiments as well as all changes and modifications falling within the scope of the embodiments of the present application.

[0089] Finally, it should be noted that in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or terminal device that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or terminal device. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or terminal device that includes said element.

[0090] The above provides a detailed description of the method, system, device, and medium for generating change records of an API detail table. Specific examples have been used to illustrate the principles and implementation methods of this application. The descriptions of the above embodiments are only for the purpose of helping to understand the method and core ideas of this application. At the same time, for those skilled in the art, there will be changes in the specific implementation methods and application scope based on the ideas of this application. Therefore, the content of this specification should not be construed as a limitation of this application.

Claims

1. A method for generating change records in an API detail table, characterized in that, The method includes: Obtain the first version API detailed table and the second version API detailed table. The second version API detailed table is obtained after updating the first version API detailed table. Data processing is performed on the first version API detail table and the second version API detail table respectively to obtain the first string dataset corresponding to the first version API detail table and the second string dataset corresponding to the second version API detail table. Compare the first string dataset with the second string dataset, and based on the comparison results, determine the updated content of the second version API detail table relative to the first version API detail table; Based on the updated content, a change record of the second version API details table relative to the first version API details table is generated.

2. The method for generating change records of API detail tables according to claim 1, characterized in that, Data processing is performed on the first version API detail table and the second version API detail table respectively to obtain a first string dataset corresponding to the first version API detail table and a second string dataset corresponding to the second version API detail table, including: Obtain the type of each data table page in the API detail table, wherein the API detail table is either the first version API detail table or the second version API detail table; Based on the type of the data table page, and according to the unique identification rules preset for the type of the data table page, the data in the data table page is processed to obtain the mapping relationship between the unique identifier and the corresponding attribute identifier in the data table page. The attribute identifier includes multiple attribute data. Based on the mapping relationship between the unique identifiers and corresponding attribute identifiers in each data page of the API detail table, the string dataset corresponding to the API detail table is determined, and the string dataset is either the first string dataset or the second string dataset.

3. The method for generating change records of API detail tables according to claim 2, characterized in that, The step of determining the string dataset corresponding to the API detail table based on the mapping relationship between unique identifiers and corresponding attribute identifiers in each data page of the API detail table includes: Use the unique identifier in the data table page as the primary index item; The attribute identifier corresponding to the unique identifier is used as the associated field name of the main index item; The multiple attribute data associated with the attribute identifier are used as multiple data fields associated with the associated field name, wherein each data field corresponds to a data field name, and the data field name is determined based on the mapping relationship between the keyword element in the data field and the column coordinate of the data field. The main index item, the associated field name corresponding to the main index item, and the multiple data fields associated with the associated field name are concatenated to obtain the string dataset corresponding to the API detail table.

4. The method for generating change records of API detail tables according to claim 1, characterized in that, The comparison between the first string dataset and the second string dataset includes: Iterate through the first unique identifier in the first string dataset, and query whether there is a second unique identifier in the second string dataset. If no second unique identifier corresponding to the first unique identifier is found in the second string dataset, determine that the second version API detail table has undergone a deletion-type change relative to the first version API detail table, and record the corresponding deleted data fields. The first unique identifier corresponds to the second unique identifier. Iterate through the second unique identifier in the second string dataset, and query whether the first unique identifier exists in the first string dataset. If no first unique identifier corresponding to the second unique identifier is found in the first string dataset, determine that the second version of the API details table has a new class change relative to the first version of the API details table, and record the corresponding new data field.

5. The method for generating change records of API detail tables according to claim 4, characterized in that, If a second unique identifier corresponding to the first unique identifier is found in the second string dataset, or if a first unique identifier corresponding to the second unique identifier is found in the first string dataset, the method further includes: Obtain the first target data field under the target associated field name of the first unique identifier, and the second target data field under the same target associated field name of the second unique identifier. The target associated field name is either the first unique identifier or the second unique identifier, and the first target data field and the second target data field correspond to each other. Based on preset delimiter rules, the first target data field is parsed into a first data sequence, and the second target data field is parsed into a second data sequence; The first data sequence and the second data sequence are compared item by item, and the data items that differ from each other, as well as the associated field name and data field name of the data items that differ from each other, are recorded.

6. The method for generating change records of API detail tables according to claim 1, characterized in that, Based on the updated content, a change record of the second version API detail table relative to the first version API detail table is generated, including: Based on the updated content, the data table pages are categorized according to their types to obtain the updated content corresponding to each data table page. Based on the update content corresponding to each of the data table pages, the updates are categorized by type, and different types of update content are displayed in their respective label areas to generate a change record of the second version API detail table relative to the first version API detail table.

7. The method for generating change records of API detail tables according to claim 1, characterized in that, Before processing the data in the first version API detail table and the second version API detail table, the method further includes: The format of the data table pages in the API details table is checked for validity. The API details table is either the first version of the API details table or the second version of the API details table. If the format of a data page in the API details table is found to be invalid, the data processing for the API details table will be terminated and a prompt message will be output. If the format of the data page in the API details table is found to be valid, the column coordinate information of each attribute data in the data page is recorded, and a mapping relationship is established between the keyword element of each attribute data and the corresponding column coordinate information.

8. A system for generating change records for API detail tables, characterized in that, The system includes: The acquisition module is used to acquire the first version API detail table and the second version API detail table, wherein the second version API detail table is obtained after the first version API detail table is updated. The data processing module is used to process the first version API detail table and the second version API detail table respectively to obtain the first string dataset corresponding to the first version API detail table and the second string dataset corresponding to the second version API detail table. The data comparison module is used to compare the first string dataset with the second string dataset, and based on the comparison results, determine the updated content of the second version API details table relative to the first version API details table; The generation module is used to generate a change record of the second version API detail table relative to the first version API detail table based on the updated content.

9. An electronic device, characterized in that, It includes a memory, a processor, and a program or instructions stored in the memory and executable on the processor, wherein the program or instructions, when executed by the processor, implement the steps of the method for generating a change record of the API detail table as claimed in any one of claims 1-7.

10. A readable storage medium on which a program or instructions are stored, characterized in that, When the program or instructions are executed by the processor, they implement the steps of the method for generating change records of the API detail table as described in any one of claims 1-7.

Images