An API collaborative publishing method, apparatus, control device, and readable storage medium.

Abstract

This application provides an API collaborative release method, apparatus, control device, and readable storage medium. The method includes: in response to metadata containing API modification information entered by at least one change unit, storing the entered metadata in a relational database; the API modification information includes saved records and associated revision data; in response to a release request from the change unit, merging the revision data associated with the currently saved record of the change unit with the revision data associated with the currently released API version; and releasing the merged revision data as a new API version. This method retains the collaborative revision data of all previously released change units while incorporating the current revision data of the change unit into the API version, achieving excellent collaborative release results. Furthermore, the release request can be initiated by any change unit, making it more flexible in application.

Description

Technical Field

[0001] This application relates to the field of computer technology, and more specifically, to an API collaborative publishing method, apparatus, control device, and readable storage medium. Background Technology

[0002] APIs are the core of enterprise capability openness. More and more services are being opened up through APIs, which has also triggered the rapid development of the API economy in the industry to a certain extent.

[0003] API design is a complex management process due to its intricate metadata structure and extensive configuration. A single API change typically takes over a week from design to deployment. This results in multiple developers needing to modify the same API queuing up and waiting for the previous change to be released before they can proceed. The entire design management process becomes sequential, leading to extremely low efficiency in collaborative scenarios. Summary of the Invention

[0004] The problem this application addresses is the extremely low efficiency of collaborative API publishing among multiple users.

[0005] To address the aforementioned issues, the first aspect of this application provides an API collaborative publishing method, comprising:

[0006] In response to metadata containing API modification information entered by at least one change unit, the entered metadata is stored in a relational database; the API modification information includes saved records and associated revision data;

[0007] In response to the release request of the change unit, the revision data associated with the currently saved record of the change unit is merged with the revision data associated with the currently released API version;

[0008] The merged revised data will be released as a new API version.

[0009] A second aspect of this application provides an API collaborative publishing apparatus, comprising:

[0010] A metadata entry module is used to store the entered metadata containing API modification information in a relational database in response to metadata entered by at least one change unit; the API modification information includes saved records and associated revision data;

[0011] A data merging module is used to merge the revision data associated with the currently saved record of the change unit with the revision data associated with the currently released API version in response to the release request of the change unit.

[0012] The API publishing module is used to publish the merged revised data as a new API version.

[0013] A third aspect of this application provides a control device comprising: a memory and a processor;

[0014] The memory is used to store programs;

[0015] The processor, coupled to the memory, is used to execute the program for:

[0016] In response to metadata containing API modification information entered by at least one change unit, the entered metadata is stored in a relational database; the API modification information includes saved records and associated revision data;

[0017] In response to the release request of the change unit, the revision data associated with the currently saved record of the change unit is merged with the revision data associated with the currently released API version;

[0018] The merged revised data will be released as a new API version.

[0019] A fourth aspect of this application provides a computer-readable storage medium having a computer program stored thereon, the program being executed by a processor to implement the API collaborative publishing method described above.

[0020] The collaborative release method in this application not only retains the collaborative revision data of all previously released change units, but also adds the revision data of the current change unit to the API version, achieving a very good collaborative release effect. Moreover, the release request can be made by any change unit, making it more flexible in application.

[0021] By storing data in a relational database, highly efficient retrieval capabilities can be supported; relational databases are commonly used databases, and using a relational database for storage can avoid additional cost issues such as access costs and maintenance costs; it does not rely on a file system, thus achieving extremely fast response speeds. Attached Figure Description

[0022] Figure 1 This is a flowchart of an API collaborative publishing method according to an embodiment of this application;

[0023] Figure 2 This is a flowchart of an API collaborative publishing method S200 according to an embodiment of this application;

[0024] Figure 3 This is a flowchart of an API collaborative publishing method S200 according to another embodiment of this application;

[0025] Figure 4 This is a flowchart of an API collaborative publishing method S200 according to another embodiment of this application;

[0026] Figure 5 This is a flowchart of an API collaborative publishing method according to another embodiment of this application;

[0027] Figure 6 Here is an architecture diagram of an example API collaborative release scheme;

[0028] Figure 7 Architecture diagram of the data entry module for example API collaborative release;

[0029] Figure 8 An example diagram of the data storage module published in collaboration with the sample API;

[0030] Figure 9 This is a structural block diagram of an API collaborative publishing apparatus according to an embodiment of this application;

[0031] Figure 10 This is a structural block diagram of a control device according to an embodiment of this application. Detailed Implementation

[0032] To make the above-mentioned objects, features, and advantages of this application more apparent and understandable, specific embodiments of this application will be described in detail below with reference to the accompanying drawings. Although exemplary embodiments of this application are shown in the drawings, it should be understood that this application can 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.

[0033] It should be noted that, unless otherwise stated, the technical or scientific terms used in this application shall have the ordinary meaning as understood by one of ordinary skill in the art to which this application pertains.

[0034] APIs are the core of enterprise capability openness and an important capability medium in the overall digital transformation of enterprises. More and more services are being opened through APIs, which has also triggered the rapid development of the API economy in the industry to a certain extent. The opening of APIs cannot be separated from a complete API lifecycle solution, which includes the entire process of planning, design, implementation, testing, release, operation and maintenance, consumption, version control and API decommissioning.

[0035] Among these processes, API design is a relatively complex management process because its metadata structure is intricate and its configuration content is extensive. A single API change typically takes more than a week from design to deployment. This results in multiple developers needing to make changes to the same API having to wait in a queue until the previous change is released before they can proceed. The entire design management process becomes sequential, and in collaborative scenarios involving multiple developers, it is extremely inefficient.

[0036] In addition, metadata is not limited to APIs; there are also other data such as runtime strategies and routing management. Supporting multiple metadata management methods brings additional development costs.

[0037] Git is a well-known collaborative version control tool, so a common industry solution is to split the system's data, with the parts requiring collaborative work managed using Git, and other data relying on a relational database. While this solution solves the problem of multi-user collaboration, it still has the following issues:

[0038] Because Git relies on the file system, the overall system response speed is slow, resulting in a poor user experience for developers. Git is not designed for searching, so it cannot efficiently support metadata retrieval capabilities. Git also has high integration and maintenance costs.

[0039] To address the aforementioned issues, this application provides a novel API collaborative publishing solution that can store modified content in a relational database and merge it with the currently published API version during publishing, thereby resolving the problem of low collaborative efficiency when multiple people collaborate on API publishing.

[0040] For ease of understanding, the following terms may be used and are explained below:

[0041] API stands for Application Programming Interface, which defines the interaction between multiple software intermediaries. In the internet age, a website's services are encapsulated into a series of easily recognizable data interfaces and made available to third-party developers; these data interfaces are called APIs.

[0042] API Full Lifecycle Management: This encompasses the entire process of API lifecycle management, including planning, design, implementation, testing, release, operation, consumption, version control, and API sunset.

[0043] Metadata, or data about data, refers to structured data extracted from information resources to describe their characteristics and content. It is used for organizing, describing, retrieving, storing, and managing information and knowledge resources. Complex metadata specifically refers to metadata with complex structures and rich configuration content.

[0044] Management System: An information system that manages specific business operations.

[0045] Git: Git is a distributed version control tool.

[0046] LCA algorithm: Least Common Ancestors, refers to the algorithm that finds the lowest common ancestor of two nodes u and v in a directed acyclic graph.

[0047] JSONPatch: JSONPatch is a format for describing changes in JSON data, used for diffing structured data and merging data.

[0048] Diff Algorithm: The essence of the diff algorithm is to find the differences between two objects. The core of the diff algorithm is to compare the child node arrays, and the idea is to compare the beginning and end.

[0049] Directed Acyclic Graph (DAG): In graph theory, if a directed graph cannot be returned to a vertex by traversing several edges, then the graph is a directed acyclic graph (DAG). Because a vertex in a directed graph may not form a cycle by traversing two different paths to reach another vertex, a directed acyclic graph may not be convertible into a tree, but any directed tree is a directed acyclic graph.

[0050] This application provides an API collaborative publishing method, which can be executed by an API collaborative publishing device that can be integrated into electronic devices such as tablets, computers, servers, computer clusters, and data centers. Figure 1 The diagram shown is a flowchart of an API collaborative publishing method according to an embodiment of this application; wherein, the API collaborative publishing method includes:

[0051] S100, in response to metadata containing API modification information entered by at least one change unit, the entered metadata is stored in a relational database; the API modification information includes saved records and associated revision data;

[0052] S200, in response to the release request of the change unit, merge the revision data associated with the currently saved record of the change unit with the revision data associated with the currently released API version;

[0053] S300, the merged revised data is released as a new API version.

[0054] It is understandable that by modifying the saved records in the API modification information, all modification traces of a change unit can be identified.

[0055] It should be noted that in this application, the change unit is regarded as a collaborative individual unit, and one change unit can be a login account, a user, or an organization.

[0056] In this application, the change unit is treated as a collaborative individual unit. When multiple change units collaborate, each change unit enters API modification information, and the entered API modification information is stored in a relational database. Each change unit submits a release request based on its own actual situation. Upon receiving a release request from a change unit, the latest revision data of that change unit is merged with the revision data of the latest released API version, and the merged revision data is released as the new API version. Alternatively, the revision data of the already released API version can be retained, and the revision data of the change unit can be added to the latest API version for release. In this way, the collaborative revision data of all previously released change units is retained, and the revision data of the current change unit is added to the API version, achieving a very good collaborative release effect. Moreover, the release request can be submitted by any change unit, making the application more flexible.

[0057] For example: If units A, B, C, and D all entered API modification information and subsequently released API versions, then the API version released by unit A includes the API modification information of unit A; the API version released by unit B includes the API modification information of units A and B; the API version released by unit C includes the API modification information of units A, B, and C; and the API version released by unit D includes the API modification information of units A, B, C, and D. Therefore, it can be considered that units A, B, C, and D collaboratively released the latest API version (containing the API modification information of units A, B, C, and D).

[0058] The collaborative release method in this application not only retains the collaborative revision data of all previously released change units, but also adds the revision data of the current change unit to the API version, achieving a very good collaborative release effect. Moreover, the release request can be made by any change unit, making it more flexible in application.

[0059] By storing data in a relational database, highly efficient retrieval capabilities can be supported; relational databases are commonly used databases, and using a relational database for storage can avoid additional cost issues such as access costs and maintenance costs; it does not rely on a file system, thus achieving extremely fast response speeds.

[0060] In one implementation, the relational database stores the identifier of the change unit, the save record associated with the change unit, and the revision data associated with the save record; it also stores the save record associated with the currently released API version and the revision data associated with the save record; upon receiving metadata entered by the change unit, the database stores the save record in the entered metadata and the revision data associated with the save record, and updates the entered save record to the current save record of the change unit.

[0061] By associating the identifier of the change unit, the saved record of the change unit, and the revision data of each saved record, efficient retrieval can be supported.

[0062] In one implementation, the release request of the change unit includes an identifier of a saved record. Upon receiving the release request, the saved record corresponding to the identifier is released as the current saved record of the change unit.

[0063] In one implementation, the release request of the change unit does not include an identifier for the saved record. Upon receiving the release request, the current saved record of the change unit is released.

[0064] In one implementation, such as Figure 2 As shown, the relational database stores the progressive relationships between the saved records; merging the revision data associated with the current saved record of the change unit with the revision data associated with the currently released API version includes:

[0065] S201, establish a directed acyclic graph based on the saved records and the progressive relationship between the saved records;

[0066] S202, determine the first saved record associated with the currently released API version, the current saved record of the change unit, and the saved record of their common ancestor in the directed acyclic graph;

[0067] S203, if the first saved record is consistent with the common ancestor saved record, the revised data associated with the current saved record is used as the merged revised data.

[0068] In one implementation, the progressive relationship between the saved records is a reference relationship between them. For example, if saved record A is obtained by modifying saved record B, then saved record A references saved record B, and saved record A and saved record B have a progressive relationship.

[0069] It is understood that when the progressive relationship between the saved records is a reference relationship between the saved records, each saved record in the directed acyclic graph is obtained by modifying its ancestor saved record; the first saved record is consistent with the common ancestor saved record, which means that the current saved record of the change unit is obtained by modifying the common ancestor and the first saved record, and the revision data associated with the current saved record can be directly used as the merged revision data.

[0070] In one implementation, the progressive relationship between multiple saved records of the same change unit can be a temporal relationship, a reference relationship, or other relationships.

[0071] In one implementation, the identifier for a change unit is an index. The version index identifies a change unit and points to the saved record corresponding to the current data. Each time new modified data is added to a change unit, a new saved record is generated, and the index is set to point to that record. Within the version index, there is only one official index, representing the published data change version; other changes can have multiple versions simultaneously, and these are merged with the data belonging to the official index during final release, thus supporting multi-user collaboration.

[0072] In one implementation, the record is used to record information such as the modifier, modification time, and modification description, while also pointing to the data corresponding to this modification.

[0073] In one implementation, the revised data is used to store specific data content, which is the complete data after revision.

[0074] In one implementation, the revised data also records the SHA1 signature (hash function signature) of the data.

[0075] As you can understand, the SHA1 value of data is the digital fingerprint of the data, and it is unique. Each piece of data corresponds to a unique SHA1 value, which is generally used to confirm whether your data is consistent with the officially released data. If the official original data is modified, then the calculated SHA1 value will be different.

[0076] By using the SHA1 signature, duplicate revision data can be eliminated. This way, when the same content needs to be saved, there is no need to regenerate the revision data; the saved record can simply point to the already saved revision data.

[0077] When revising data in a change unit, duplicate saving often occurs due to user habits.

[0078] In one implementation, such as Figure 3As shown, merging the revision data associated with the currently saved record of the change unit with the revision data associated with the currently released API version further includes:

[0079] S204, if the first saved record is inconsistent with the common ancestor saved record, the revised data associated with the common ancestor saved record is used as the base data, the revised data associated with the first saved record is used as the official data, and the revised data associated with the current saved record of the change unit is used as the change data.

[0080] S205, determine the diff results between the baseline data and the official data and the changed data based on the diff algorithm;

[0081] S206, Based on the diff result and the preset merging strategy, obtain the merged revised data.

[0082] It is understood that the current saved record of the change unit is obtained by modifying the common ancestor, and the first saved record is also obtained by modifying the common ancestor.

[0083] In this application, the specific process of determining the diff result using the diff algorithm will not be described in detail.

[0084] In this application, the revised data after merging is obtained based on the diff result and a preset merging strategy. This can be achieved as follows: if neither branch of a specific field has been modified, the merging result is based on the baseline data; if only one branch of a specific field has been modified, the merging result is based directly on the modified data; if both branches of a specific field have been modified and the modified data values ​​are the same, the merging result is based on the modified data of any branch; if both branches of a specific field have been modified and the modified data values ​​are inconsistent, they need to be marked as conflicting and resolved manually.

[0085] In terms of specific implementation, two sets of patches are generated through JSON Patch, and it is checked whether there are data operations that modify the same path in the two sets of patches. Then, the two sets of patches are merged according to the merging rules to generate the final data. Finally, the conflicting data operations are converted into conflict text and generated into the final data for users to view and resolve conflicts.

[0086] In one implementation, such as Figure 4 As shown, after obtaining the merged revised data, the method further includes:

[0087] S211, add a save record in the relational database, associate the save record with the merged revision data, and update the save record to the save record associated with the currently released API version and the current save record of the change unit.

[0088] In one implementation, such as Figure 5 As shown, in S100, prior to the entry of metadata containing API modification information by at least one change unit, the method further includes:

[0089] S101, declare the format of the metadata that is allowed to be entered.

[0090] In one implementation, after declaring the format of the metadata that is allowed to be entered, step S101 further includes:

[0091] S102, Generate a metadata editor based on the declaration, so that the change unit can enter the metadata through the metadata editor;

[0092] S103, Validate the format of the entered metadata according to the statement.

[0093] The statement defines the format of metadata through a format specification description language (such as JSONSchema). Based on this description, a metadata editor can be generated, and the format of user-entered data can be validated, ultimately producing structured data that conforms to the specification.

[0094] This application summarizes that when it is necessary to add metadata types, only the corresponding format specification description (declaration) needs to be added, and the expansion cost is extremely low.

[0095] In one implementation, the statement records an identifier corresponding to the allowed metadata format, and the format corresponding to the metadata is identified by the identifier in the entered metadata.

[0096] Specifically, such as Figure 6-8 As shown in the figure, the specific process of API collaborative publishing in this application will be explained in detail.

[0097] The API collaborative publishing solution in this application includes: a data entry module, a change management module, and a data storage module. The specific structure is as follows: Figure 6 As shown, the data entry module provides data editing capabilities while constraining the data structure to prevent unexpected configurations. Each metadata type has a corresponding data entry module. The change management module is primarily used to manage data and enable multi-user collaboration. The data storage module stores data using a relational database.

[0098] The data entry module includes a metadata editor, a format validator, and a format specification description. For example... Figure 7 As shown, the format of metadata is defined through a format specification description language, and a metadata editor and format validator are generated based on this; finally, structured data that conforms to the specification is obtained.

[0099] The change management module enables metadata changes in multi-user collaborative scenarios. Its core capability is change merging: when a user publishes changed data, the module automatically merges the modifications already published by other users to prevent data loss.

[0100] The data storage module, such as Figure 8 As shown, its function is to provide a storage structure design that supports multi-user collaboration based on a relational database. The stored data is divided into the following three types: version index, saved records, and revision data.

[0101] In addition, a method for merging changed data is provided, which includes the following steps:

[0102] S110: Construct a directed acyclic graph O based on the saved records of the official version index, then jump to S120;

[0103] S120: Set the save record indices corresponding to the official and change records to F and C respectively, and find their common save record index B in Figure O as the baseline data, then jump to S130;

[0104] S130: Check if index F and index B are consistent. If they are consistent, jump to S190; otherwise, jump to S140.

[0105] S140: Read the data corresponding to indices F, C and B respectively, and jump to S150;

[0106] S150: Perform diffs between the baseline data and the official and changed data respectively, then jump to S160;

[0107] S160: Determine if there are data conflicts based on the diff results and merging strategy. If there are conflicts, proceed to S180; otherwise, proceed to S170.

[0108] S170: Merge the data and generate a new saved record, and change the index C to point to that record, then jump to S190;

[0109] S180: Conflict text is generated and returned to the user for resolution, ending the overall process.

[0110] S190: Point the original index F to the modified index C, and the entire process ends.

[0111] In this application, multi-user collaboration is achieved based on a relational database: compared to file systems, which are more suitable for storing large files, relational databases are inherently suitable for adding, deleting, modifying, and querying structured metadata, with obvious performance advantages and a better user experience.

[0112] In this application, since it only relies on the database, the overall deployment and maintenance costs of the system are lower.

[0113] Combination Figure 8 For example:

[0114] Figure 8 In the document, the version index section includes Change 1, Change 2, and the official index; the saved records include Save 1, Save 2, Save 3, and Save 4, where Save 3 is the current saved record of Change 1, and Save 3, Save 2, and Save 1 have a reference / progression relationship; Save 4 is the current saved record of Change 2, and Save 4 and Save 1 have a reference / progression relationship; the revision data section includes version1, version2, and version3; where version1 is associated with Save 1, version2 is associated with Save 2 and Save 3, and version3 is associated with Save 4.

[0115] Based on this, we first collaboratively publish Change 1 (as indicated by the dashed arrow in the figure). We determine that the first save record associated with the currently published API version is Save 1, the current save record of Change 1 is Save 3, and the common ancestor save record of Save 1 and Save 3 is Save 1. Therefore, we directly use the revision data of Save 3 as the merged revision data and update Save 3 to the save record associated with the currently published API version. This is to change the association relationship of the official index to Save 3 (as indicated by the dashed arrow in the figure).

[0116] This application provides an API collaborative publishing device for executing the API collaborative publishing method described above. The API collaborative publishing device will be described in detail below.

[0117] like Figure 9 As shown, the API collaborative publishing device includes:

[0118] Metadata entry module 101 is used to store the entered metadata containing API modification information in a relational database in response to metadata entered by at least one change unit; the API modification information includes saved records and associated revision data;

[0119] The data merging module 102 is used to merge the revision data associated with the currently saved record of the change unit with the revision data associated with the currently released API version in response to the release request of the change unit.

[0120] API publishing module 103 is used to publish the merged revised data as a new API version.

[0121] In one implementation, the relational database stores the identifier of the change unit, the save record associated with the change unit, and the revision data associated with the save record; and stores the save record associated with the currently released API version and the revision data associated with the save record; the metadata entry module 101 is further configured to:

[0122] After receiving the metadata entered by the change unit, the saved record in the entered metadata and the revised data associated with the saved record are stored, and the entered saved record is updated to the current saved record of the change unit.

[0123] In one embodiment, the relational database stores the progressive relationships between the saved records; the data merging module 102 is further configured to:

[0124] A directed acyclic graph is established based on the saved records and the progressive relationships between them; the first saved record associated with the currently released API version, the current saved record of the change unit, and the common ancestor saved record of the two in the directed acyclic graph are determined; if the first saved record is consistent with the common ancestor saved record, the revision data associated with the current saved record is used as the merged revision data.

[0125] In one embodiment, the data merging module 102 is further configured to:

[0126] If the first saved record is inconsistent with the common ancestor saved record, the revised data associated with the common ancestor saved record is used as the base data, the revised data associated with the first saved record is used as the official data, and the revised data associated with the current saved record of the change unit is used as the change data; the diff results between the base data and the official data and the change data are determined based on the diff algorithm; the merged revised data is obtained based on the diff results and a preset merging strategy.

[0127] In one embodiment, the data merging module 102 is further configured to:

[0128] A new record is added to the relational database, and the record is associated with the merged revision data. The record is then updated to be the record associated with the currently released API version and the current record of the change unit.

[0129] In one embodiment, the device is further configured to:

[0130] The format of the metadata that is allowed to be entered is declared.

[0131] In one embodiment, the device is further configured to:

[0132] A metadata editor is generated based on the statement, so that the change unit can enter the metadata through the metadata editor; the format of the entered metadata is validated according to the statement.

[0133] In one implementation, the statement records an identifier corresponding to the allowed metadata format, and the format corresponding to the metadata is identified by the identifier in the entered metadata.

[0134] The API collaborative publishing device and the API collaborative publishing method provided in the above embodiments of this application are based on the same inventive concept and have the same beneficial effects as the methods adopted, run or implemented by the applications stored therein.

[0135] The above describes the internal functions and structure of the API collaborative publishing device, such as... Figure 10 As shown, in practice, this API collaborative publishing device can be implemented as a control device, including: memory 301 and processor 303.

[0136] Memory 301 can be configured to store a program.

[0137] Additionally, memory 301 can be configured to store various other data to support operation on the control device. Examples of this data include instructions for any application or method used to operate on the control device, contact data, phonebook data, messages, pictures, videos, etc.

[0138] The memory 301 can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic storage, flash memory, magnetic disk or optical disk.

[0139] Processor 303, coupled to memory 301, is used to execute programs in memory 301 for:

[0140] In response to metadata containing API modification information entered by at least one change unit, the entered metadata is stored in a relational database; the API modification information includes saved records and associated revision data;

[0141] In response to the release request of the change unit, the revision data associated with the currently saved record of the change unit is merged with the revision data associated with the currently released API version;

[0142] The merged revised data will be released as a new API version.

[0143] In one implementation, the relational database stores the identifier of the change unit, a save record associated with the change unit, and the revision data associated with the save record; and stores a save record associated with the currently released API version and the revision data associated with the save record; the processor 303 is specifically used for:

[0144] After receiving the metadata entered by the change unit, the saved record in the entered metadata and the revised data associated with the saved record are stored, and the entered saved record is updated to the current saved record of the change unit.

[0145] In one implementation, the relational database stores the progressive relationships between the saved records; the processor 303 is specifically used for:

[0146] A directed acyclic graph is established based on the saved records and the progressive relationships between them; the first saved record associated with the currently released API version, the current saved record of the change unit, and the common ancestor saved record of the two in the directed acyclic graph are determined; if the first saved record is consistent with the common ancestor saved record, the revision data associated with the current saved record is used as the merged revision data.

[0147] In one implementation, processor 303 is specifically used for:

[0148] If the first saved record is inconsistent with the common ancestor saved record, the revised data associated with the common ancestor saved record is used as the base data, the revised data associated with the first saved record is used as the official data, and the revised data associated with the current saved record of the change unit is used as the change data; the diff results between the base data and the official data and the change data are determined based on the diff algorithm; the merged revised data is obtained based on the diff results and a preset merging strategy.

[0149] In one implementation, processor 303 is specifically used for:

[0150] A new record is added to the relational database, and the record is associated with the merged revision data. The record is then updated to be the record associated with the currently released API version and the current record of the change unit.

[0151] In one implementation, processor 303 is specifically used for:

[0152] The format of the metadata that is allowed to be entered is declared.

[0153] In one implementation, processor 303 is specifically used for:

[0154] A metadata editor is generated based on the statement, so that the change unit can enter the metadata through the metadata editor; the format of the entered metadata is validated according to the statement.

[0155] In one implementation, the statement records an identifier corresponding to the allowed metadata format, and the format corresponding to the metadata is identified by the identifier in the entered metadata.

[0156] In this application, Figure 10 The diagram only shows some components and does not mean that the control device includes only these components. Figure 10 The components shown.

[0157] The control device provided in this embodiment is based on the same inventive concept as the API collaborative publishing method provided in this application embodiment, and has the same beneficial effects as the methods adopted, run or implemented by the applications stored therein.

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

[0159] This application is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this application. It will 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 apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart... Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0160] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function 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.

[0161] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable 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.

[0162] In a typical configuration, a computing device includes one or more processors (CPU), input / output interfaces, network interfaces, and memory.

[0163] Memory may include non-persistent storage in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM. Memory is an example of computer-readable media.

[0164] This application also provides a computer-readable storage medium corresponding to the API collaborative publishing method provided in the foregoing embodiments, wherein a computer program (i.e., a program product) is stored thereon, and the computer program, when run by a processor, executes the API collaborative publishing method provided in any of the foregoing embodiments.

[0165] Computer-readable media includes both permanent and non-permanent, removable and non-removable media that can store information using any method or technology. Information can be computer-readable instructions, data structures, modules of programs, or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, digital versatile optical disc (DVD) or other optical storage, magnetic tape, magnetic magnetic disk storage or other magnetic storage devices, or any other non-transferable medium that can be used to store information accessible by a computing device. As defined herein, computer-readable media does not include transient computer-readable media, such as modulated data signals and carrier waves.

[0166] The computer-readable storage medium provided in the above embodiments of this application and the API collaborative publishing method provided in the embodiments of this application are based on the same inventive concept and have the same beneficial effects as the methods adopted, run or implemented by the applications stored therein.

[0167] It should be noted that numerous specific details are set forth in the specification provided herein. However, it will be understood that embodiments of this application may be practiced without these specific details. In some instances, well-known structures and techniques have not been shown in detail so as not to obscure the understanding of this specification.

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

[0169] The above description is merely an embodiment of this application and is not intended to limit the scope of this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of the claims of this application.

Claims

1. An API cooperative publishing method, characterized by, The method comprises: storing the metadata entered by the at least one change unit in a relational database in response to the metadata recording API modification information; the API modification information comprises a save record and associated revision data; in response to a release request of the change unit, merging the revision data associated with the current save record of the change unit and the revision data associated with the currently released API version; releasing the merged revision data as a new API version.

2. The method of claim 1, wherein, The relational database stores the identification of the change unit, the save record associated with the change unit, and the revision data associated with the save record; and stores the save record associated with the currently released API version and the revision data associated with the save record; After receiving the metadata entered by the change unit, store the save record in the entered metadata and the revision data associated with the save record, and update the entered save record as the current save record of the change unit.

3. The method of claim 1, wherein, The relational database stores the progressive relationship between the save records; The merging of the revision data associated with the current save record of the change unit and the revision data associated with the currently released API version comprises: establishing a directed acyclic graph according to the save record and the progressive relationship between the save records; determining a first save record associated with the currently released API version, a current save record of the change unit, and a common ancestor save record of the two in the directed acyclic graph; if the first save record is consistent with the common ancestor save record, the revision data associated with the current save record is used as the merged revision data.

4. The method of claim 3, wherein, The merging of the revision data associated with the current save record of the change unit and the revision data associated with the currently released API version further comprises: if the first save record is inconsistent with the common ancestor save record, the revision data associated with the common ancestor save record is found as reference data, the revision data associated with the first save record is found as formal data, and the revision data associated with the current save record of the change unit is found as change data; determining the diff result of the reference data with the formal data and the change data based on a diff algorithm; obtaining the merged revision data based on the diff result and a preset merging strategy.

5. The method of claim 4, wherein, After obtaining the merged revision data, the method further comprises: adding a save record in the relational database, associating the save record with the merged revision data, and updating the save record as the save record associated with the currently released API version and the current save record of the change unit.

6. The method of claim 1, wherein, Before receiving the metadata entered by the at least one change unit recording API modification information, the method further comprises: declaring the format of the metadata allowed to be entered.

7. The method of claim 1, wherein, After declaring the format of the metadata allowed to be entered, the method further comprises: A metadata editor is generated according to the declaration, so that the change unit enters the metadata through the metadata editor; The entered metadata is checked according to the declaration.

8. The method of claim 6, wherein, The declaration records an identifier corresponding to the allowed metadata format, and the format corresponding to the metadata is identified through the identifier in the entered metadata.

9. An API cooperative publishing apparatus characterized by comprising: Comprise: A metadata entry module, for storing the entered metadata in a relational database in response to the metadata entered by at least one change unit, the metadata recording API modification information, the API modification information comprising a save record and associated revision data; A data merging module, for merging the revision data associated with the current save record of the change unit with the revision data associated with the currently published API version in response to a publishing request of the change unit; An API publishing module, for publishing the merged revision data as a new API version.

10. A control device, characterized by Comprise: A memory and a processor; The memory is used to store a program; The processor is coupled to the memory and is used to execute the program, so as to: Store the entered metadata in a relational database in response to the metadata entered by at least one change unit, the metadata recording API modification information, the API modification information comprising a save record and associated revision data; Merge the revision data associated with the current save record of the change unit with the revision data associated with the currently published API version in response to a publishing request of the change unit; Publish the merged revision data as a new API version.

Images