Intelligent update of application programming interface

Abstract

A computer-implemented method may specify a source version and a target version of an application programming interface (API) and a target programming language; and retrieving a difference graph connected from a source knowledge graph characterizing a source version of the API to a target knowledge graph characterizing a target version of the API. The difference map includes one or more revision edges representing a change in the API between the source version and the target version. The method may install one or more function packages written in a target programming language and associated with one or more revision edges; and running the one or more function packages to update the API from the source version to the target version.

Description

Technical Field

[0001] The present disclosure relates to intelligent updating of application programming interfaces. Background Art

[0002] Software development is a continuous process. Typically, multiple independently developed software applications can interact with each other via application programming interfaces (APIs). APIs define protocols that specify how different software applications can exchange data and interact with each other. In other words, APIs are software intermediaries that allow different software applications to communicate with each other. Unfortunately, keeping all software applications working in sync with the latest APIs is nearly impossible, as different software applications may have different lifecycles. Furthermore, a software application may not be aware of all of its API consumers, i.e., other software modules that interact with the software application through its API. As software development models shift from traditional monolithic architectures (where applications are built as a single, unified unit) to microservices architectures (where applications can be divided into a collection of smaller, independent units), the development of distributed and cloud computing further exacerbates these issues, as the APIs of many microservices can be distributed across many locations, and each API can have its own unique lifecycle. As a result, managing software updates and corresponding API updates can be extremely risky and expensive for enterprises. Therefore, there is room for improvement in managing software API updates. Summary of the Invention

[0003] This summary is provided to introduce some concepts in a simplified form that are further described below in the detailed description. This summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used to limit the scope of the claimed subject matter.

[0004] According to one aspect of the present disclosure, a computer-implemented method is provided, comprising: specifying a source version and a target version of an application programming interface (API) and a target programming language; retrieving a difference graph connected from a source knowledge graph representing the source version of the API to a target knowledge graph representing the target version of the API, wherein the difference graph includes one or more revision edges representing changes in the API between the source version and the target version; installing one or more function packages written in the target programming language and associated with the one or more revision edges; and running the one or more function packages to update the API from the source version to the target version.

[0005] According to another aspect of the present disclosure, a computing system is provided, comprising: a memory; one or more hardware processors coupled to the memory; and one or more computer-readable storage media storing instructions, which, when loaded into the memory, cause the one or more hardware processors to perform operations, the operations comprising: specifying a source version and a target version of an application programming interface (API) and a target programming language; retrieving a difference graph connected from a source knowledge graph representing the source version of the API to a target knowledge graph representing the target version of the API, wherein the difference graph includes one or more revision edges representing changes in the API between the source version and the target version; installing one or more function packages written in the target programming language and associated with the one or more revision edges; and running the one or more function packages to update the API from the source version to the target version.

[0006] According to another aspect of the present disclosure, one or more non-transitory computer-readable media are provided, having computer-executable instructions encoded thereon, the computer-executable instructions causing one or more processors to execute a method, the method comprising: specifying a source version and a target version of an application programming interface (API) and a target programming language; retrieving a difference graph connecting from a source knowledge graph representing the source version of the API to a target knowledge graph representing the target version of the API, wherein the difference graph includes one or more revision edges representing changes in the API between the source version and the target version; installing one or more function packages written in the target programming language and associated with the one or more revision edges; and running the one or more function packages to update the API from the source version to the target version, wherein at least one of the function packages is configured to change the data type of a metadata object from the source version of the API to the target version of the API. BRIEF DESCRIPTION OF THE DRAWINGS

[0007] Figure 1 is a high-level block diagram of an example framework for API management.

[0008] Figure 2 is another high-level block diagram of an example framework for API management and example data communication within the framework.

[0009] Figure 3 is an overall block diagram of an example computing system that includes an API registry for managing API updates.

[0010] Figure 4 is an example diagram showing a portion of a knowledge graph.

[0011] Figure 5 is a block diagram illustrating an example registration unit of an API registry.

[0012] Figure 6 is a flow chart illustrating an example overall method of transforming software code of an API into a knowledge graph representing the API.

[0013] Figure 7 A portion of software code depicting an example API.

[0014] Figure 8 Depicts from Figure 7 The API software code is generated as part of the API specification document.

[0015] Figure 9 Depicts from Figure 8 The API specification document transforms part of the knowledge graph.

[0016] Figure 10 is a flow chart illustrating an example overall method of publishing API updates to an API registry to notify selected subscribers of the relevant API updates.

[0017] Figure 11 is a flow chart illustrating an example overall method of generating a difference graph representing changes between two different versions of an API.

[0018] Figure 12 Depicted are portions of two knowledge graphs representing two different versions of an API.

[0019] Figure 13 Depicted Figure 12 The difference between the two versions of the API changes the part of the knowledge graph.

[0020] Figure 14 Depicted are portions of two difference knowledge graphs representing changes between three different versions of an API.

[0021] Figure 15 Depicted through the merger Figure 14 A part of the difference knowledge graph of two difference knowledge graphs.

[0022] Figure 16 is a high-level flowchart illustrating an example process for manually viewing and editing a knowledge graph automatically generated by an API registry.

[0023] Figure 17 is an example user interface that displays a knowledge graph representing a selected version of an API.

[0024] Figure 18 is an example user interface that displays a diff graph representing the changes between two different versions of an API.

[0025] Figure 19 is an example user interface through which subscribers to the API registry can create subscription profiles.

[0026] Figure 20is a sample user interface through which subscribers of the API registry can evaluate the effects of API updates through simulation.

[0027] Figure 21 is an overall block diagram of an example computing system including an API update platform for facilitating intelligent API updates.

[0028] Figure 22 This is an example process flow for performing smart API updates.

[0029] Figure 23 is a flow chart illustrating an example overall method of performing smart API updates.

[0030] Figure 24 Revision edges of annotated example diff graphs are shown.

[0031] Figure 25 Describes example implementations of common standard actions in Java.

[0032] Figure 26 Describes the Figure 25 Example implementations of common standard action rounding functions in Java and Python.

[0033] Figure 27 Depicts an example user interface for implementing standard actions.

[0034] Figure 28 Depicts a sample user interface for implementing custom actions.

[0035] Figure 29 Depicted is an example interpretation platform configured to convert predefined standard or custom actions into functions written in a specific programming language.

[0036] Figure 30 Depicts an example central storage system that supports smart API updates.

[0037] Figure 31 is a sample UI showing options for API updates.

[0038] Figure 32 is a sample UI that prompts the user to update the API.

[0039] Figure 33 is an example user interface that provides a ranked list of available diff graphs for the update API.

[0040] Figure 34 Different combinations of difference graphs linking knowledge graphs representing different versions of an API are shown.

[0041] Figure 35is an example user interface that provides a ranked list of available sub-change graphs that can be combined to generate a desired difference graph.

[0042] Figure 36 is an example user interface that allows a user to find community proposals for implementing changes to an API represented by revision edges of a difference graph.

[0043] Figure 37 is an example user interface that provides a ranked list of available actions designed to implement an API change.

[0044] Figure 38 is an example user interface that provides a ranked list of available actions that are considered potential candidates for implementing an API change.

[0045] Figure 39 is an example user interface that provides a list of default actions that can be used to implement predefined API changes.

[0046] Figure 40 is a block diagram of an example computing system in which the described techniques may be implemented.

[0047] Figure 41 is a block diagram of an example cloud computing environment that can be used in conjunction with the techniques described herein. DETAILED DESCRIPTION

[0048] Example 1 - Overview of API Management

[0049] Software providers frequently release new versions of their software applications to provide new features and / or fix bugs. Consequently, software providers also frequently update the APIs associated with the corresponding software applications. Clients who consume or utilize the APIs can choose to integrate the updated APIs into their software applications or continue using the older API versions. Traditionally, communication regarding API updates between software providers and clients is asynchronous. For example, clients may not be immediately notified of a software provider's release of a new API. The potential impact of API updates on existing software applications can also be difficult to assess.

[0050] A challenging issue for software providers is API lifecycle management, which refers to the process of overseeing an API throughout its lifecycle, from its creation to its retirement. For example, a software provider not only needs to provide updated APIs that work with newly released software applications, but also needs to maintain old versions of some APIs that work with some legacy applications that some customers may still use. Prematurely retiring an old version of an API may break the applications of some customers that still rely on the old version of the API. However, maintaining old versions of APIs, especially if there are many old versions of the API spanning many years, can be very expensive for software providers. Therefore, maintaining old versions of APIs that are not actively used by customers represents a significant waste of resources. API lifecycle management becomes even more complex when considering distributed APIs across multiple clouds and on-premises deployments. For example, it may be difficult for a software provider to know how many customers are still using old versions of an API, and it may be even more difficult to know what features in those old versions of the API are still being used.

[0051] Another challenging issue faced by software providers and / or technical experts who focus on API upgrades is that the impact of API changes is often unknown. For example, an API upgrade may crash the software application of some customers, but the same API upgrade may run smoothly for other customers. One reason behind this difference may involve the consuming applications that interact with the API and their technology stack. For example, some Java implementations may not care about changes in the order of attributes. But in another instance, when creating INSERT statements for a relational database, the order of attributes may be critical for the program to run correctly. As another example, some applications may ignore attributes completely and have no problem handling type changes, while other applications may rely on specific data types.

[0052] On the customer side, API management also presents numerous challenges. Today, API integration is essential for any organization deploying enterprise software applications, as each organization may rely on dozens or hundreds of third-party APIs, each of which can have significant downstream impacts on the organization's normal operations. While ideally, one would want to keep all APIs up-to-date, this is often not feasible for many organizations, as frequent API updates can incur high costs and / or increase downtime. As a result, some organizations may forgo API updates until necessary. For example, an organization may choose to continue using older versions of an API, despite the fact that these older versions may not take advantage of some useful features in a newly released software application. Sometimes, an organization may have to devise workarounds to make the older version of an API compatible with other applications. However, an organization may eventually have to upgrade its APIs. This may occur, for example, when a software provider stops supporting an older version of an API and / or the older version of the API may be incompatible with some critical software applications. As another example, regulatory requirements (e.g., new regulatory features in accounting or reporting, etc.) and / or security concerns may force an organization to upgrade certain APIs.

[0053] When an organization performs an API upgrade, more problems may occur. For example, the new version of the API may have breaking changes compared to the old version of the API. As a result, upgrading the API from the old version to the new version may crash the organization's other software applications or make them inoperable. Identifying what those breaking changes are can be extremely challenging. For example, some of the API changes between different versions may not be formally documented. In order to debug the problem, a manual comparison between the old API and the new API may be necessary. This can be very tedious because some APIs may have hundreds of attributes, and manually spotting minor changes (e.g., a data type update from CHAR(4) to CHAR(5), a change in attribute order, etc.) can be extremely difficult. Even if all API changes are meticulously documented, pinpointing which changes have caused the crashing condition may require complex analysis, especially if there are several intermediate versions of the API between the old and new versions (in which case, multiple versions of the API must be traced back to debug the problem). In addition, the new version of the API may have "hidden" breaking changes that do not cause problems immediately after the initial API upgrade, but may cause crashes at some point in the future. This can happen, for example, when a destructive condition does not exist at the time of an API upgrade but manifests itself later.

[0054] Furthermore, even if all API changes are correctly identified, implementing these API changes often requires special expertise. Finding and hiring professionals to implement the desired API changes can be time-consuming and expensive.

[0055] The techniques described in this article can address many of the aforementioned issues and can be applied across a wide variety of enterprise software environments.

[0056] Example 2 - Example framework for API management

[0057] Figure 1 is a high-level block diagram depicting an example computing framework 100 for an API management API according to the techniques described herein.

[0058] The computing framework 100 includes an API registry 120 that serves as a central messaging platform for connecting providers and consumers of APIs. Figure 1 As shown, a software provider of an API, represented as an API publisher 110 (which may also be referred to as an API provider), may publish different versions of the API on an API registry 120. Consumers of the API, represented as API subscribers 130, may register with the API registry 120. In some examples, the API registry 120 may include a message broker configured to send customized messages to selected API subscribers 130 using certain messaging protocols upon receiving an API published by the API publisher 110. Although Figure 1 Only one API publisher 110 and two API subscribers 130 are shown, but it will be understood that there may be more than one API publisher 110 and the number of API subscribers 130 may be one or more than two.

[0059] As described more fully below, the API registry 120 is technology-agnostic and can transform the software code of the API published by the API publisher 110 (including metadata objects and data values ​​embedded in the API) into a knowledge graph and store the knowledge graph in a knowledge graph repository (also known as a "triple store"). Based on the knowledge graph representation of different versions of the API, the API registry 120 can further identify changes between different versions of the API and also represent these changes in a knowledge graph format (e.g., a difference graph as described below).

[0060] The API subscribers 130 may create corresponding profiles (e.g., subscription profiles) on the API registry 120 that specify the API change conditions that each individual API subscriber 130 is interested in. For example, an API subscriber may create a profile that includes specific API change conditions that are relevant to the implementation of that particular API subscriber (e.g., API changes that may affect software applications running on the API subscriber's computing environment).

[0061] Upon detecting identified changes between different versions of an API, the API registry 120 can automatically send a message including a customized alert to selected API subscribers 130 based on their respective profiles. Importantly, the customized alert is implemented in a manner relevant to each recipient of the message. Furthermore, notifications to API subscribers 130 can be synchronized with and / or nearly instantaneous after the API publisher 110 publishes the API.

[0062] In addition, both API publishers 110 and API subscribers 130 can perform simulations using the API registry 120. For example, the API publisher 110 can simulate how many API subscribers 130 will be affected by an API upgrade or downgrade based on the profiles stored on the API registry 120. The API subscribers 130 can also simulate what will happen to software applications running on the API subscriber's computing environment (e.g., in terms of compatibility or incompatibility) if the API is upgraded or downgraded.

[0063] Business decisions can be made based on the simulation results. For example, if the impact of an API upgrade is unlikely to cause problems for many API subscribers 130, the API publisher 110 may decide to release a newer version of the API with limited technical support. If, for example, based on profiling, it is found that few API subscribers 130 are interested in certain features implemented in the old version of the API, the API publisher 110 may also decide to retire the old version of the API. Furthermore, based on the simulation results, API subscribers 130 can decide whether it is worth investing resources in upgrading the API.

[0064] Figure 2 is another high-level block diagram of an example computing framework 200 for API management. Figure 1 In the example of FIG. 2 , the computing framework 200 includes an API registry 220 that interacts with an API provider 210 and an API subscriber 230. Figure 2 Only one API publisher 210 and one API subscriber 230 are shown, but it will be understood that there may be more than one API publisher 210 and / or more than one API subscriber 230. An API registry 220, which may be similar to the API registry 120 described above, may be implemented in a cloud environment 240.

[0065] Figure 2Also shown are some example data communications within the framework 200. For example, an API publisher 210 can publish different versions of an API, and these published APIs can be registered on the API registry 220 in a knowledge graph format. The API publisher 210 can perform simulations on the API registry to estimate the impact of API changes on consumers of the API, and receive simulation results from the API registry 200. The API publisher 210 can also query the API registry 200 to determine the number of API subscribers 230 who are still actively using certain versions of the API based on the API's profile.

[0066] like Figure 2 As shown, API subscriber 230 can subscribe to API registry 220 and create a profile on API registry 220. After subscribing, if a new version of the API meets one of the API change conditions specified in the subscriber's profile, API subscriber 230 can immediately receive a message or notification from API registry 220 after the new version of the API is registered on API registry 220. API subscriber 230 can also run simulations on API registry 220 to determine the impact of upgrading and / or downgrading the API on software applications running on the subscriber's computing environment. In addition, API subscriber 230 can provide feedback about the published API to API publisher 210 through API registry 220.

[0067] Example 3 - Example Overview of an API Registry System

[0068] Figure 3 The overall block diagram of an example computing system 300 supporting message-based API management is shown. The system 300 includes an API registry 320, which can be Figure 1 The API registry depicted in 120 or Figure 2 An example embodiment of the API registry 220 is depicted in FIG.

[0069] like Figure 3 As shown, the API registry 320 may include a registration unit 330, a transformation unit 340, and a subscription unit 350. The API registration unit 330 may include a knowledge graph (KG) generator 332 and a knowledge graph storage or repository 334 (which may also be referred to as a triple store). The transformation unit 340 may include a predecessor and transformation maintenance module 342, a transformation storage module 344, and a proposal engine 346. The subscription unit 350 may include a subscription service module 352 and a subscription configuration storage 354.

[0070] In some examples, the published API can be registered on the API registry 320 through the registration unit 330. Specifically, the knowledge graph generator 332 can transform the software code of the API into a knowledge graph representation of the API. The generated knowledge graph can be stored in the knowledge graph storage 334.

[0071] The generated knowledge graph can be analyzed by the transformation unit 340. For example, the differences between two knowledge graphs representing two different versions of an API can be automatically identified by the predecessor and transformation maintenance module 342. The predecessor and transformation maintenance module 342 can also represent the identified differences in a graph format (e.g., a difference graph), as further described below. The transformation storage module 344 can store the generated difference graph.

[0072] In some examples, a user 302, such as an API registry administrator or a software developer of an API (representing an API publisher), can access the API registry through the transformation unit 340. For example, the proposal engine 346 can display the knowledge graph automatically generated by the knowledge graph generator 332 in a graphical user interface, and the user 302 can view, annotate, and / or modify the knowledge graph through the graphical user interface. In addition, the proposal engine 346 can also display a difference graph automatically generated by the predecessor and transformation maintenance module 342 on the graphical user interface, and the user 302 can view, annotate, and / or modify the difference graph through the graphical user interface.

[0073] In some examples, API subscribers can subscribe to the API registry 320 via a subscription unit 350. Specifically, each API subscriber can create its own profile (e.g., a subscription configuration file) using a subscription service module 352. The API subscriber's profile can specify the API change conditions that the API subscriber is interested in. The collection of profiles of all API subscribers can be stored in a subscription configuration storage 354.

[0074] In practice, the systems shown herein (such as system 300) may vary in complexity, with additional functionality, more complex components, etc. For example, additional functionality may exist within API registry 320. Additional components may be included to implement security, redundancy, load balancing, reporting, etc.

[0075] The described computing systems can be networked via wired or wireless network connections (including the Internet). Alternatively, the systems can be connected via intranet connections (e.g., in a corporate environment, government environment, etc.).

[0076] System 300 and any other systems described herein can be implemented in conjunction with any hardware components described herein, such as the computing systems described below (e.g., processing units, memory, etc.). In any examples herein, knowledge graphs, difference graphs, profiles, etc. can be stored in one or more computer-readable storage media or computer-readable storage devices. The techniques described herein can be general to the specifics of the operating system or hardware and can be applied to any type of environment to utilize the described features.

[0077] Example 4 - Example Overview of Knowledge Graph

[0078] A knowledge graph is a special type of database that maintains knowledge or information in the form of a graph. A typical knowledge graph consists of multiple nodes representing objects and multiple edges (also called "properties") connecting the nodes. Edges represent hierarchical relationships between objects (e.g., is a parent of an object, is located in an object, etc.). A common type of knowledge graph is based on the Resource Description Framework (RDF), which models statements about facts or web resources in the form of subject-verb-object expressions (called triples). For example, two nodes connected by a directional edge may describe a fact, which can be represented as a (subject, predicate, object) triple. All triples defined by a knowledge graph can be serialized into RDF files that are stored in a database called a triple store.

[0079] In some examples, the nodes in the knowledge graph can be organized in a hierarchical structure, where lower-level nodes (representing more specific objects) can be connected to higher-level nodes (representing more general objects) through one or more edges. Lower-level nodes (or lower-level objects they represent) can be referred to as descendants or child nodes of higher-level nodes (or higher-level objects they represent), and higher-level nodes (or higher-level objects they represent) can be referred to as ancestors or parent nodes of lower-level nodes (or lower-level objects they represent).

[0080] As an example, Figure 4A portion of a DBpedia knowledge graph 400 is shown, containing four nodes 410 representing objects for SAP_SE, Germany, company, and country, respectively. The knowledge graph 400 also includes directional edges or attributes 420 representing hierarchical relationships between the nodes 410, such as type, location of founding, and year of establishment. Data values ​​such as the string 1972-01-01 can be considered leaf nodes or value nodes 430 of the knowledge graph. As described herein, a leaf node or value node refers to a node in the knowledge graph that has no child nodes. In other words, a leaf node (value node) can be connected to one or more parent nodes via an edge pointing from a parent node to the leaf node (value node), but there is no edge originating from the leaf node (value node). In RDF schemas, value nodes can be defined by the class "rdfs:Literal". As shown, the knowledge graph can contain several facts, such as (SAP_SE is a type of company), (SAP_SE has a location of founding, Germany), (Germany is a country), and (SAP_SE has a year of establishment, 1972-01-01).

[0081] Typically, an object represented by a node can include an identifier and a label representing the object's name. A node can also have an associated Uniform Resource Identifier (URI) (sometimes also called a Uniform Resource Locator or URL). The relationships represented by edges can be characterized by a set of edge attributes specific to the knowledge graph. Each edge attribute can also have a unique URI.

[0082] The nodes in a knowledge graph can form a hierarchy. Some nodes can represent more specific objects and can be considered as instances contained in the knowledge graph. For example, SAP_SE can be an instance representing a specific Company, and Germany can be an instance representing a specific Country. Strings (e.g., 1972-01-01) can also be considered as instances. Some nodes can represent more general objects and can be considered as classes. For example, Company is a class that captures common concepts shared by many individual companies, including SAP_SE, and Country is a class that captures common concepts shared by many individual countries, including Germany. According to the RDF schema, the rdfs:subClassOf property can be used to indicate that one class is a subclass of another class. For example, the statement ":EuropeanState rdfs:subClassOf:State" indicates that the class EuropeanState is a subclass of another class State.

[0083] There can be different ways to distinguish between instances and classes. For example, a knowledge graph can have predefined property prefixes that can indicate whether a node is an instance or a class (e.g., if a node has the prefix "dbo" which represents a DBpedia ontology, the node can be considered a class, and if a node has the prefix "dbr" which represents a DBpedia resource, the node can be considered an instance). In some cases, a knowledge graph can use URI design to distinguish between instances and classes. In some cases, a knowledge graph can include statements that explicitly indicate that certain nodes are classes. In some cases, whether a particular node represents an instance or a class can depend on the underlying model or concept. For example, in DBpedia, whether a node is a class (and therefore belongs to the knowledge graph's ontology) or an instance (and therefore is not included in the knowledge graph's ontology) can be determined by examining the rdf:type property: if the type is owl:Class, then it is a class and belongs to the ontology; otherwise, it is considered an instance and does not belong to the ontology.

[0084] Edges or properties in a knowledge graph define relationships between subject resources (e.g., the nodes from which the edge originates) and object resources (e.g., the nodes to which the edge points). In some cases, edges or properties in a knowledge graph can also form a hierarchy. According to RDF schemas, the rdfs:subPropertyOf property can be used to indicate that a property is a subproperty of another property. For example, the statement ":capitalOf rdfs:subPropertyOf :locatedIn" indicates that the edge or property capitalOf is a subproperty of another edge or property locatedIn.

[0085] For a given knowledge graph, an ontology can be created by describing classes with a list of attributes represented by edges. In other words, the aggregation of all classes and edges in the knowledge graph can define an ontology. For example, the DBpedia ontology currently covers more than 600 classes of objects, which form a subsumption hierarchy and are described by more than 2000 different edge attributes.

[0086] As described in this paper, the ontology of a knowledge graph can contain patterns or common vocabulary that define the edges or properties of the nodes available in the knowledge graph. For example, Figure 4 The ontology of the knowledge graph depicted in defines at least the following attributes of the instance SAP_SE: type, foundationPlace, and foundingYear. In addition, Figure 4 The ontology of the knowledge graph depicted in also defines at least the following two classes: Company and Country.

[0087] In some knowledge graphs (e.g., RDF knowledge graphs), one can also apply reasoning to (subject, predicate, object) triples (e.g., instead of explicitly stating that Germany is a country, as in Figure 4 As shown). For example, according to the pre-built inference rules, every object of dbo:foundationPlace is a country (by setting the attribute scope). Therefore, by reasoning, the triple (Germany, Type, Country) can be "inferred" or "materialized" into the factual statement: "Germany is a country". Other inference rules can be constructed similarly. In addition, some inference rules can include restrictions on certain nodes and / or edges. For example, one restriction can be that the node Company cannot represent a person. Another restriction can be that the starting point of the founding year must be an organization, and the target of the edge founding year must be a string; and so on. According to the RDF schema, restricting the starting point and target of an edge can be achieved by specifying domain and range properties. For example, the statements ":capitalOf rdfs:domain:City" and ":capitalOf rdfs:range:Country" together indicate that the starting point of the edge capitalOf must be a node representing a city (or in the domain of a city), and the target of the edge capitalOf must be a node representing a country (or in the range of a country).

[0088] Compared to relational databases, knowledge graphs have more flexible data structures because the type of data provided by the knowledge graph can change. The technology described herein can transform any software API (regardless of the language used in the API) into a corresponding knowledge graph with a universal ontology. The technology described herein can also identify differences between different versions of an API and represent such differences in a knowledge graph format. Such a graphical representation provides users with an intuitive way to analyze metadata objects within the API and helps users quickly identify, understand and / or record changes made between different versions of the API. In addition, using a central API registry, the technology described herein can generate custom alerts to selected API subscribers if certain API updates provided by an API publisher may potentially cause implementation-related issues for those API subscribers.

[0089] Example 5 - Example Knowledge Graph Registration

[0090] Figure 5 is a block diagram illustrating an example registration unit 530 of the API registry 520. The API registry 520 can be similar to the API registry 320, and the registration unit 530 can be similar to the registration unit 330. For example, the API registration unit 530 can include a graph transformer 532 (which can be an example embodiment of the knowledge graph generator 332) and a triple store 534 (which can be an example embodiment of the knowledge graph store 334).

[0091] The registration unit 530 may receive the software code of the API provided by the API publisher. In some cases, the software code of the API may be automatically sent, for example, by the system agent 510 of the API provider. For example, the system agent 510 may be a software application running on the computing system of the API provider. Whenever a new version of the API is compiled, verified, and ready for release, the system agent 510 may push the new version of the API to the registration unit 530. In some cases, the software code of the API may be manually sent to the registration unit 530, for example, by a user 512. After receiving the software code of the API, the graph transformer 532 may be triggered to convert the software code of the API into a knowledge graph, which may then be stored in the triple store 534.

[0092] In some examples, the graph transformer 532 may include one or more adapters 511 (also referred to as converters), such as a Web Services Description Language (WSDL) adapter, a Swagger adapter, and the like. Such adapters may parse the software code of an API to extract metadata objects and schematic data values ​​therein, and generate a corresponding text-based API specification document that describes such metadata objects and data values ​​in a standard format. For example, a WSDL adapter may parse the software code of an API for a Simple Object Response and Schema (SOAP) web service and organize the extracted API metadata objects in a WSDL document format, and a Swagger adapter may parse the software code of an API for a RESTful (Representation State Transfer) service and describe the extracted API metadata objects in JSON or YAML format. In some examples, additional data processing may be performed to organize the extracted metadata objects and associated data values ​​into a desired data format (e.g., the metadata objects may be tabulated, etc.). As described herein, the graph transformer 532 may be configured to generate a knowledge graph representation of an input API based on a text-based API specification document generated by one of the adapters 531.

[0093] As a result, even if the input API may be written in different programming languages, the metadata objects and related data values ​​of the API can be extracted by the corresponding adapter 531. Even if the text-based API specification documents generated by different adapters 531 may have different formats, the knowledge graph generated by the graph transformer 532 can also have a common ontology. In other words, the generated knowledge graph is technology-agnostic because all APIs (regardless of their underlying technology) can be universally represented by a knowledge graph with the same ontology.

[0094] Example 6 - Example Overall Approach to Generating a Knowledge Graph Representation of an API

[0095] Figure 6 is a flowchart of an example overall method 600 for generating a knowledge graph representation of an API, and may be, for example, represented by Figure 5 The graph converter 532 or Figure 3 The knowledge graph generator 332 is executed.

[0096] At 610, method 600 may receive software code for an API. At 620, method 600 may generate a knowledge graph representation of the API based on the software code for the API. In some examples, the received software code for the API may first be transformed into a text-based API specification document (e.g., by one of adapters 511). The text-based API specification document may then be converted into a knowledge graph representation of the API.

[0097] like Figure 6 As shown, step 620 may include two sub-steps: At 630, method 600 may instantiate a plurality of nodes representing metadata objects and data values ​​associated with the API. In some examples, the metadata objects and data values ​​associated with the API may be extracted by a corresponding adapter (e.g., 531), as described above. Then, at 640, method 600 may create a plurality of edges connecting the plurality of nodes. The plurality of edges define a hierarchical relationship between the metadata objects and data values ​​represented by the plurality of nodes.

[0098] Method 600 and any other methods described herein can be performed by computer-executable instructions (e.g., causing a computing system to perform the method) stored in one or more computer-readable media (e.g., storage devices or other tangible media) or stored in one or more computer-readable storage devices. Such methods can be implemented in software, firmware, hardware, or a combination thereof. Such methods can be performed, at least in part, by a computing system (e.g., one or more computing devices).

[0099] Example 7 — Example ontology representing a knowledge graph for an API

[0100] In any of the examples described herein, the knowledge graph representation of the API can have a predefined ontology containing schemas defining node types and edges (attributes) for nodes available in the knowledge graph.

[0101] In some examples, the ontology of a knowledge graph representing an API can have the following node types or classes: RootNode representing a specific API; SubNode representing a structural element or metadata object of the API; Value representing a data value of the API (holding schematic elements). Typically, each knowledge graph representation of an API can have one root node representing the API (with node type RootNode), multiple child nodes representing metadata objects of the API (with node type SubNode), and multiple value nodes representing schematic data values ​​of the API (with node type Value).

[0102] In some examples, each child node in the knowledge graph can include one or more properties or fields, such as a label (e.g., rdfs:label), a description or comment field (e.g., rdfs:comment), etc. The properties of the child node can represent the corresponding attributes of the metadata object represented by the child node. In some examples, the ontology of the knowledge graph representing the API can also include a node type Datatype, which represents different data types of metadata objects or data values ​​(e.g., represented as strings).

[0103] It will be understood that the above labels for node types are merely exemplary, and that different naming conventions may be used to label node types. Furthermore, it will be understood that the number of node types may be greater or less than the number of node types described above. For example, in some cases, Datatype may be optional. As another example, an ontology representing a knowledge graph of an API may define additional node types as needed.

[0104] In addition, the ontology representing the knowledge graph of the API can have multiple predefined edges or properties. For example, the ontology can define an edge or property hasSubnode with a scope of SubNode (i.e., the edge points to SubNode). As another example, the ontology can define an edge or property hasDatatype with a scope of Datatype (i.e., the edge points to Datatype).

[0105] In some examples, the ontology of the knowledge graph representing the API can define an edge or property with a scope of RootNode called hasPriorVersion. In this scenario, an edge can point from the root node of the knowledge graph representing the current version of the API to the root node of another knowledge graph representing the previous version of the API (i.e., the version immediately before the current version).

[0106] In some examples, the ontology of the knowledge graph representing the API may define an edge or property with scope RootNode called hasApiChangeVersion. In this case, an edge may point from a child node of a knowledge graph representing the current version of the API to the root node of another knowledge graph representing an earlier version of the API, where the metadata object represented by the child node was last changed.

[0107] In some examples, the ontology of the knowledge graph representing the API may define an edge or property initiallyIntroducedInVersion with a scope of RootNode and a domain of SubNode. In this case, an edge may point from a child node of the knowledge graph representing the current version of the API to the root node of another knowledge graph representing an earlier version of the API, where the metadata object represented by the child node was first introduced.

[0108] In some examples, the ontology of the knowledge graph representing the API may define a pair of edges or properties hasMinCardinality (having a minimum cardinality) and hasMaxCardinality (having a maximum cardinality), both of which may have an Integer range. These two edges or properties may point from the selected child node to two value nodes, which respectively represent the minimum cardinality and maximum cardinality of the metadata object represented by the selected child node.

[0109] In some examples, the ontology of the knowledge graph representing the API may define an edge or property hasVersion that can have a string range of (String). In this case, the edge can point from the root node of the knowledge graph to a value node representing the version number of the API represented by the knowledge graph (e.g., represented as a String).

[0110] In some examples, the ontology representing the knowledge graph of the API may define an edge or property HierarySequenceNumber that may have an Integer range. In this case, an edge may point from a child node to a value node that represents the hierarchical sequence number of the child node within the knowledge graph.

[0111] In some examples, the ontology of the knowledge graph representing the API may define an edge or property hasApiPort that may have an Integer range. In this case, the edge may point from the root node of the knowledge graph to a value node that represents the port number provided by the API publisher for accessing the API represented by the knowledge graph.

[0112] In some examples, the ontology of the knowledge graph representing the API may define an edge or property lastChanged that may have a Date range. In this case, the edge may point from the root node (or child node) of the knowledge graph to a value node representing the date when the API represented by the knowledge graph (or the corresponding metadata object represented by the child node) was last modified.

[0113] In some examples, the ontology representing the knowledge graph of the API may define an edge or property isKey that may have a Boolean range. In this case, an edge may point from a child node to a value node that indicates whether the metadata object represented by the child node has the keyword property.

[0114] It will be understood that the above-mentioned labels of edges or attributes are merely exemplary, and different naming conventions may be used to label edges or attributes. In addition, it will be understood that some of the above-mentioned edges or attributes (e.g., isKey, hasApiPort, hasPriorVersion, hasApiChangeVersion, initiallyIntroducedInVersion, etc.) may be optional, and additional edges or attributes may be included in the ontology as needed.

[0115] Example 8 - Example method to create nodes and edges representing the knowledge graph of an API

[0116] This article describes Figure 6 Additional information about the method 600 is provided in FIG.

[0117] In some examples, multiple nodes are instantiated (e.g., Figure 6 Step 630 of the API may include instantiating a root node (e.g., having a node type of RootNode) that identifies the API, instantiating one or more value nodes (e.g., having a node type of Value) that represent data values ​​associated with the API, and instantiating one or more child nodes (e.g., having a node type of SubNode) that represent metadata objects associated with the API. As described herein, a child node can be connected to another child node or a value node via one of a plurality of edges.

[0118] In some examples, multiple edges are created (e.g., Figure 6 Step 640 of the embodiment may include creating an edge connecting a first child node (e.g., having a node type of SubNode) to a second child node (e.g., having a node type of SubNode). The created edge may indicate that the first metadata object represented by the first child node includes the second metadata object represented by the second child node.

[0119] In some examples, multiple edges are created (e.g., Figure 6 Step 640 of the embodiment may include creating an edge connecting a child node (e.g., having a node type of SubNode) to a value node (e.g., having a node type of DataType). The created edge may indicate that the metadata object represented by the child node has a specific data type represented by the value node (e.g., represented as a string).

[0120] In some examples, multiple edges are created (e.g., Figure 6 Step 640 of the step 641 may include creating an edge from a child node (e.g., having a node type of SubNode) to a value node (e.g., having a node type of Value). The value node may represent a version of the API (e.g., represented as a string), where the metadata object represented by the selected child node is first introduced.

[0121] In some examples, multiple edges are created (e.g., Figure 6 Step 640 of the method may include creating edges connecting a child node (e.g., having a node type of SubNode) to two value nodes (e.g., having a node type of Value). The two leaf nodes may represent the minimum cardinality and the maximum cardinality (e.g., represented by Integer) of the metadata object represented by the child node, respectively.

[0122] In some examples, multiple edges are created (e.g., Figure 6 Step 640 of ) may include creating an edge connecting a root node (eg, having a node type RootNode) to a value node (eg, having a node type Value) representing a current version of the API (eg, represented as a string).

[0123] Example 9 - Example use case for generating a knowledge graph representation of an API

[0124] You can use this article as a reference Figure 7-Figure 9 An example is described to further illustrate method 600 .

[0125] Figure 7 A portion of software code 700 for an example API for CostCenter is depicted. Figure 8 Depicts from Figure 7 8. The API specification document 800 may be generated, for example, using a WSDL adapter configured to parse the software code 700. In the depicted example, the API specification document 800 includes tabulated metadata objects (e.g., ID, name, attributes, etc., which may be nested to define a hierarchical structure) and schematic data values ​​(e.g., cardinality, etc.) for the API.

[0126] Figure 9 Depicts from Figure 8 800 . As shown in the figure, the knowledge graph 900 includes a plurality of nodes representing metadata objects and data values ​​embedded in the software code 700 of the CostCenter API and included in the API specification document 800 .

[0127] The nodes include a root node 910 representing the CostCenter API and multiple child nodes and value nodes interconnected by edges (attributes). For example, the root node 910 is connected to multiple child nodes 920, 922, 924, and 926 (representing ID, BusinessCharacterValidityPeriod (business character validity period), name, and attribute, respectively) via corresponding edges 911, 913, 915, and 917 (e.g., having a hasSubnode attribute).

[0128] like Figure 9 As shown, multiple nodes are arranged in a hierarchy. For example, node 922 (BusinessCharacterValidityPeriod) is connected to its two child nodes 940 and 942 (representing StartDate and EndDate, respectively) via corresponding edges 921 and 923 (e.g., having a hasSubnode attribute); node 924 (Name) is connected to its three child nodes 944, 946, and 948 (representing Name, Description, and ActionCode, respectively) via corresponding edges 925, 927, and 929 (e.g., having a hasSubnode attribute); node 926 (Attributes) are connected to their child nodes 950, 952, etc. (representing CompanyFinancialAccounting, HomeBusinessSystemID, etc., respectively) via corresponding edges 931, 933, etc. (e.g., having hasSubnode attributes); nodes 944 (Name) and 946 (Description) are connected to their corresponding child nodes 960, 962 (both representing languageCode) via corresponding edges 951, 953 (e.g., having hasSubnode attributes); and so on.

[0129] For clarity, from Figure 9Some nodes are omitted. For example, node 948 (ActionCode) can be connected via two edges (e.g., with attributes hasMinCardinality and hasMaxCardinality) to two value nodes representing the minimum and maximum cardinality of the ActionCode. As another example, root node 910 can be connected to a value node representing the version number of the CostCenter API (e.g., with attribute hasVersion).

[0130] Example 10 - Example Overall Approach to Message-Based API Management

[0131] Figure 10 is a flow chart illustrating an example overall method 1000 for message-based API management and may be executed, for example, by the computing system 100 , 200 , or 300 described above.

[0132] At 1010 , a software provider (eg, API publisher 110 or 220 ) may register a new version of an API with an API registry (eg, 120 , 220 , 320 , 520 , etc.).

[0133] At 1020, the API registry may be registered using, for example, the API registry referenced above. Figure 6 The described method 600 transforms a new version of a registered API into a first knowledge graph.

[0134] At 1030, the API registry may compare the first knowledge graph with the second knowledge graph to determine a difference graph (which may also be referred to as a "difference knowledge graph" or "delta knowledge graph" or "change graph"). The second knowledge graph may be transformed from a previous version of the API. The difference graph connects the second knowledge graph to the first knowledge graph and identifies changes from the second knowledge graph to the first knowledge graph.

[0135] At 1040 , the API registry may send the difference graph to selected entities (eg, one or more of API subscribers 130 and 230 ) that have subscribed to the API registry.

[0136] In some examples, each entity that has subscribed to the API registry can create a custom subscription profile (also referred to as a "subscription profile"). The subscription profile can specify API change conditions that will trigger the difference graph to be sent from the API registry to the entity. In response to determining that the identified change from the second knowledge graph to the first knowledge graph satisfies at least one of the API change conditions specified in the entity's subscription profile, the API registry will notify the entity (e.g., via a message broker) of the identified change. In other words, the entity will receive a notification if and only if the API change fits within the entity's subscription profile.

[0137] The API change condition may include any change identified in the difference graph. Example API change conditions may include: creating a new node in the first knowledge graph, deleting a node in the second knowledge graph, changing the data type of a node shared by both the first knowledge graph and the second knowledge graph, etc., as further described below.

[0138] For each entity that has subscribed to the API registry, the subscription profile can specify only those API change conditions that the entity is interested in. Therefore, even if the difference graph indicates that there are many API changes, it is possible that only a subset of these API changes (or even no API changes) meet the API change conditions specified in the entity's subscription profile. As a result, the entity will not receive notifications for API change conditions that the entity is not interested in.

[0139] For example, if an entity's subscription profile includes only one API change condition, which is a change in the data type of a particular node, the entity will receive a notification from the API registry if and only if the particular node changes its data type from the second knowledge graph to the first knowledge graph. Other identified changes in the difference graph (e.g., addition and / or deletion of nodes) will not trigger notifications to the entity. As another example, if an entity's subscription profile includes two API change conditions, e.g., addition of new nodes and deletion of existing nodes, the entity will receive a notification any time an existing node in the second knowledge graph is deleted from the first knowledge graph, or any time a new node is introduced in the first knowledge graph (i.e., the node does not exist in the second knowledge graph). Other identified changes in the difference graph (e.g., changes in the data type of certain nodes) will not trigger notifications to the entity.

[0140] Example 11 - Example ensemble method for generating a difference map

[0141] Figure 11 is a flow chart illustrating an overall method 1100 for generating a difference graph representing changes between two different versions of an API, and may be used, for example, by Figure 3 The predecessor and transformation maintenance module 342 is executed.

[0142] At 1110, method 1100 may receive a first knowledge graph transformed from a first version of the API (eg, using the method described above with reference to Figure 6 In some examples, the first knowledge graph can be retrieved from a knowledge graph store (e.g., 334).

[0143] At 1120, method 1100 may receive a second knowledge graph transformed from a second version of the API (eg, using the method described above with reference to Figure 6 In some examples, the second knowledge graph can be retrieved from a knowledge graph store (e.g., 334).

[0144] At 1130 , method 1100 can identify changes from the second knowledge graph to the first knowledge graph.

[0145] Such changes may include any changes to nodes or edges between the two knowledge graphs. Identification of such changes may be performed by comparing the topologies of the first knowledge graph and the second knowledge graph. For example, each knowledge graph has a tree structure, and multiple paths may be traced from the root node to each leaf node to generate multiple paths, where each path links the root node to the corresponding leaf node, for example, via zero, one or more intermediate child nodes therebetween. By comparing the paths between the first knowledge graph and the second knowledge graph, differences in nodes and / or edges between the first knowledge graph and the second knowledge graph may be identified.

[0146] At 1140 , method 1100 may generate a difference graph based on the identified changes from the second knowledge graph to the first knowledge graph.

[0147] In some examples, the difference graph may connect the second knowledge graph to the first knowledge graph via one or more revision edges. The one or more revision edges may represent identified changes from the second knowledge graph to the first knowledge graph.

[0148] Example 12 - Example Ontology of Difference Graphs

[0149] As described above, the ontology of the difference graph may include the same predefined schema representing the knowledge graph of the API. Additionally, the ontology of the difference graph may include additional predefined schemas that characterize changes in nodes and / or edges between two different knowledge graphs.

[0150] In the following examples, unless explicitly stated otherwise, it is assumed that the difference graph represents the identified changes from the second knowledge graph (eg, representing an older version of the API) to the first knowledge graph (eg, representing a newer version of the API).

[0151] In some examples, the difference graph can have some new classes or node types. An example node type is NewNode, which represents a node that exists in the first knowledge graph but not in the second knowledge graph. NewNode can represent a metadata object or data value that is introduced in a newer version of the API (and does not exist in an older version of the API). In some examples, two subclasses or subnode types (e.g., NewSubNode and NewValue) can be used to distinguish new metadata objects and new data values ​​introduced in a newer version of the API but not included in an older version of the API.

[0152] Another example node type is DeletedNode, which represents a node that exists in the second knowledge graph but not in the first knowledge graph. A DeletedNode can represent a metadata object or data value that was included in an older version of the API but not included in a newer version of the API. In some examples, two subclasses or subnode types (e.g., DeletedSubNode and DeletedValue) can be used to distinguish metadata objects and data values ​​that were deleted from an older version of the API (and not included in a newer version of the API).

[0153] In some examples, the difference graph can have some new edges or attributes, also called revision edges. Each revision edge points from a node in the second knowledge graph to a node in the first knowledge graph, where the node in the second knowledge graph can be considered a parent node and the node in the first knowledge graph can be considered a child node.

[0154] An example revision edge can be a NewNode edge that points from a parent node in the second knowledge graph to a child node in the first knowledge graph that represents the new node (e.g., having a NewNode node type). In some examples, two different revision edges or sub-attributes (e.g., NewSubNode and NewValue) can be used to connect a parent node in the second knowledge graph to child nodes in the first knowledge graph that have NewSubNode and NewValue sub-node types, respectively.

[0155] Another example revision edge can be a DeletedNode edge that points from a parent node in the second knowledge graph to a child node in the first knowledge graph (e.g., having a DeletedNode node type) that represents a deleted node. In some examples, two different revision edges or sub-attributes (e.g., DeletedSubNode and DeletedValue) can be used to connect a parent node in the second knowledge graph to a child node in the first knowledge graph that has a DeletedSubNode and a DeletedValue sub-node type, respectively.

[0156] Another example revision edge can be a PropertyChange edge that points from a parent node in the second knowledge graph to a child node in the first knowledge graph, where the parent node and the child node represent the same metadata object, but have different properties in the two versions of the API. In some examples, different revision edges or sub-properties can be used to represent different types of property changes. For example, a DatatypeChange edge can indicate that a child node has a changed data type compared to the parent node, a NameChange edge can indicate that a child node has a name change compared to the parent node, a DeletedKey edge can indicate that a keyword field in the parent node is deleted in the child node, a NewKey edge can indicate that a child node has a new keyword field that does not exist in the parent node, etc.

[0157] Example 13 - Example use case for generating a difference map

[0158] Figure 12-13 An example is shown in which a difference graph is generated based on two knowledge graphs 1200A and 1200B and represents two different versions of an API (eg, version 2.4 and version 2.5).

[0159] exist Figure 12 In the example depicted in , three differences can be identified between knowledge graphs 1200A and 1200B: First, node 1250A in knowledge graph 1200A (representing the metadata object CompanyFinancialAccounting in version 2.4 of the API) does not exist in knowledge graph 1200B, indicating that version 2.5 of the API does not have the metadata object CompanyFinancialAccounting. However, in order to generate a difference graph, a "deleted node" 1250B (corresponding to node 1250A) can be artificially created in knowledge graph 1200B. Second, node 1252A in knowledge graph 1200A (representing the metadata object HomeBusinessSystemID in version 2.4 of the API) and node 1252B in knowledge graph 1200B (representing the same metadata object HomeBusinessSystemID in version 2.5 of the API) have different data types or data formats. Third, new node 1254B in knowledge graph 1200B represents a new metadata object introduced in version 2.5 of the API, but no corresponding node exists in knowledge graph 1200A.

[0160] Figure 13A difference graph 1300 generated based on the identified differences between the two knowledge graphs 1200A and 1200B is shown. As shown, the difference graph 1300 can connect the knowledge graph 1200A to the knowledge graph 1200B via a plurality of revision edges, including: (1) a DeletedNode edge connecting from node 1250A in the knowledge graph 1200A to a "deleted node" 1250B artificially created in the knowledge graph 1200B; (2) a DatatypeChange edge connecting from node 1252A in the knowledge graph 1200A to node 1252B in the knowledge graph 1200B; and (3) a NewSubNode edge connecting from node 1226A in the knowledge graph 1200A (representing the metadata object Attributes in version 2.4 of the API) to a new node 1254B in the knowledge graph 1200B.

[0161] Example 14 - Example method for creating revision edges

[0162] This article describes an example method for creating revision edges in a difference graph.Similarly, assume that the difference graph represents the identified changes from a second knowledge graph (e.g., representing an older version of an API) to a first knowledge graph (e.g., representing a newer version of an API).

[0163] In some examples, identifying changes can include identifying a legacy node in the second knowledge graph that is not included in the first knowledge graph. As described herein, a legacy node represents a metadata object or data value that was defined in an older version of the API but not defined in a newer version of the API. When generating a difference graph, a copy of the legacy node can be created in the first knowledge graph. A delete node revision edge (e.g., with a delete node edge attribute) can be added to connect from the legacy node in the second knowledge graph to the copy of the legacy node in the first knowledge graph. The parent node of the legacy node in the second knowledge graph can be identified. The copy of the legacy node can then be connected to another node in the first knowledge graph that matches the parent node of the legacy node in the second knowledge graph.

[0164] For example, Figure 12 The change between the two knowledge graphs 1200A and 1200B identified includes a traditional node 1250A that exists in the knowledge graph 1200A but does not exist in the knowledge graph 1200B. Therefore, in order to create the difference graph 1300, a copy of the traditional node 1250A, namely 1250B, can be created in the knowledge graph 1200B. Figure 13As shown, a revision edge 1310 (with a DeletedNode edge attribute) can be added, which points from the traditional node 1250A in the knowledge graph 1200A to its copy 1250B in the knowledge graph 1200B. Because the edge 1231A (e.g., having a hasSubnode attribute) points from the node 1226A to the traditional node 1250A, the node 1226A can be identified as the parent node of the traditional node 1250A. It can be further identified that the node 1226B in the knowledge graph 1200B is a matching node of the node 1226A (i.e., the nodes 1226A and 1226B represent the same metadata object of the API). Therefore, a corresponding edge 1231B (e.g., having a hasSubnode attribute) can be added to point from the node 1226B to the node 1250B.

[0165] In some examples, identifying changes can include identifying a new node in the first knowledge graph that is not included in the second knowledge graph. As described herein, a new node represents a metadata object or data value that is defined in a newer version of the API but not in an older version of the API. When generating a difference graph, a new node revision edge (e.g., with a NewSubNode edge attribute) can be added to connect from a selected node in the second knowledge graph to the new node in the first knowledge graph. The parent node of the new node in the first knowledge graph can be identified. The selected node in the second knowledge graph can be identified as a node that matches the parent node of the new node in the first knowledge graph.

[0166] For example, Figure 12 It is shown that the changes identified between the two knowledge graphs 1200A and 1200B include a new node 1254B that exists in knowledge graph 1200B but does not exist in knowledge graph 1200A. Therefore, to create the difference graph 1300, a revision edge 1330 (with a NewSubNode edge attribute) can be added that points from the selected node 1226A in knowledge graph 1200A to the new node 1254B in knowledge graph 1200B. Here, node 1226A is selected because it matches node 1226B in knowledge graph 1200B, and node 1226B can be identified as the parent node of new node 1254B (e.g., edge 1235B with a hasSubnode attribute pointing from node 1226B to new node 1254B).

[0167] In some examples, identifying a change can include identifying a pair of matching nodes including a first node in a first knowledge graph and a second node in a second knowledge graph. The first node in the first knowledge graph represents a metadata object having a first data type, and the second node in the second knowledge graph represents the same metadata object having a second data type that is different from the first data type. When generating a difference graph, a revision edge for the data type change (e.g., with a DatatypeChange edge attribute) can be added to connect from the second node in the second knowledge graph to the first node in the first knowledge graph. Other attribute changes between a pair of nodes representing the same metadata object (e.g., name changes, adding a keyword field, deleting a keyword field, etc.) can be similarly reflected in the difference graph by adding edges between a pair of nodes with corresponding edge attributes (e.g., NameChange, NewKey, DeletedKey, etc.).

[0168] For example, Figure 12 It is shown that the identified change between the two knowledge graphs 1200A and 1200B includes a data type change from node 1252A in knowledge graph 1200A to node 1252B in knowledge graph 1200B. Therefore, to create the difference graph 1300, a revision edge 1320 (with a DatatypeChange edge attribute) can be added pointing from node 1252A in knowledge graph 1200A to node 1252B in knowledge graph 1200B.

[0169] Example 15 - Example method to concatenate or merge difference maps

[0170] In some examples, difference graphs between multiple versions of an API can be concatenated and / or merged.

[0171] For example, in Figure 11 The difference graph generated at 1140 can be represented as a first difference graph. Method 1100 can also receive a third knowledge graph transformed from a third version of the API, identify changes from the third knowledge graph to the second knowledge graph, and generate a second difference graph based on the identified changes from the third knowledge graph to the second knowledge graph. The second version of the API can be an intermediate version between the third version and the first version of the API.

[0172] Therefore, the first difference graph and the second difference graph may be connected together or concatenated using the second knowledge graph as an intermediary between the first knowledge graph and the third knowledge graph.

[0173] In some examples, the first difference graph and the second difference graph can be merged together to generate a merged difference graph. For example, the first difference graph may include one or more first revision edges connecting the second knowledge graph to the first knowledge graph, wherein the one or more first revision edges represent the identified changes from the second knowledge graph to the first knowledge graph. The second difference graph may include one or more second revision edges connecting the third knowledge graph to the second knowledge graph, wherein the one or more second revision edges represent the identified changes from the third knowledge graph to the second knowledge graph. The merged difference graph may connect the third knowledge graph to the first knowledge graph via one or more integrated revision edges based on the one or more first revision edges and the one or more second revision edges, wherein the one or more integrated revision edges represent the cumulative changes from the third knowledge graph to the first knowledge graph. The second knowledge graph may be omitted from the merged difference graph.

[0174] As an example, Figure 14 Two difference graphs 1300 and 1400 generated based on three knowledge graphs 1200A, 1200B, 1200C respectively representing three different versions of an API (eg, version 2.4, version 2.5, and version 2.6) are shown.

[0175] As described above, a difference graph 1300 is generated based on the identified differences between the two knowledge graphs 1200A and 1200B. As shown, the difference graph 1300 includes a first revised edge 1310 (having a DeletedNode edge attribute) connecting from the traditional node 1250A in the knowledge graph 1200A to the copy of the traditional node 1250B in the knowledge graph 1200B, a second revised edge 1320 (having a DatatypeChange edge attribute) connecting from the node 1252A in the knowledge graph 1200A to the node 1252B in the knowledge graph 1200B, and a third revised edge (having a NewSubNode edge attribute) connecting from the selected node 1226A in the knowledge graph 1200A to the new node 1254B in the knowledge graph 1200B.

[0176] Similarly, a difference graph 1400 can be generated based on the two identified differences between the two knowledge graphs 1200B and 1200C. First, another new node 1256C is added to the knowledge graph 1200C (and linked to its parent node 1226C). Secondly, the new node 1254B introduced in the knowledge graph 1200B has an attribute (datatype) changed in the knowledge graph 1200C. Therefore, the difference graph 1400 includes a revised edge 1410 (with a NewSubNode edge attribute) connected from the selected node 1226B in the knowledge graph 1200B (which matches the parent node 1226C) to the new node 1256C in the knowledge graph 1200C, and another revised edge 1420 (with a DatatypeChange edge attribute) connected from the node 1254B in the knowledge graph 1200B to the node 1254C in the knowledge graph 1200C.

[0177] As shown, the two difference graphs 1300 and 1400 are cascaded to link the three knowledge graphs 1200A, 1200B, and 1200C together, where the knowledge graph 1200B serves as an intermediary between the knowledge graphs 1200A and 1200C.

[0178] Figure 15 Shown by merging Figure 14 1400. As shown, the difference graph 1500 includes integrated revision edges, such as 1510, 1520, 1530, and 1540, which directly connect nodes in the knowledge graph 1200A to corresponding nodes in the knowledge graph 1200C. The knowledge graph 1200B can be omitted from the difference graph 1500 (e.g., for illustrative purposes, the related nodes 1250B, 1252B, and 1254B are omitted in the figure). Figure 15 are gray, but these nodes may be completely hidden in the merged difference graph 1500).

[0179] As shown, a revision edge 1510 (with a DeletedNode edge attribute) connects node 1250A in knowledge graph 1200A to node 1250C in knowledge graph 1200C. Node 1250C can be copied from node 1250B in knowledge graph 1200B to indicate that the deletion of legacy node 1250A from knowledge graph 1200B is propagated to knowledge graph 1200C. Similarly, node 1250C can be connected to parent node 1226C that matches node 1226A.

[0180] Revision edge 1520 (with a DatatypeChange edge attribute) connects from node 1252A in knowledge graph 1200A to node 1252C in knowledge graph 1200C, indicating that a data type change of the underlying metadata object (e.g., from node 1252A to node 1252B) is persisted to node 1252C.

[0181] A revision edge 1530 (with a NewSubNode edge attribute) connects node 1226A in knowledge graph 1200A to node 1256C in knowledge graph 1200C, indicating that node 1256C is newly introduced in knowledge graph 1200C. Parent node 1226C of node 1256C in knowledge graph 1200C matches node 1226A in knowledge graph 1200A (i.e., nodes 1226A and 1226C represent the same metadata object of the API).

[0182] A revision edge 1540 (with a combined NewSubNode and DatatypeChange edge attribute) connects node 1226A in knowledge graph 1200A to node 1254C in knowledge graph 1200C. This indicates that the metadata object represented by node 1254C was first introduced in an intermediate version of the API (e.g., version 2.5 represented by knowledge graph 1200B) and subsequently had a change in data type. Similarly, the parent node 1226C of node 1254C in knowledge graph 1200C matches node 1226A in knowledge graph 1200A.

[0183] In some examples, it may not be necessary to first generate two difference knowledge graphs 1300 and 1400 and then merge them together to generate the difference graph 1500. Instead, the difference graph 1500 can be generated directly by using the above method 1100, for example, based on the identified changes from knowledge graph 1200A to knowledge graph 1200C, without examining the intermediate knowledge graph 1200B. This approach can simplify computation and reduce memory usage (e.g., there is no need to save multiple difference graphs).

[0184] In other examples, it may be desirable to generate a series of difference graphs between different versions of an API and then merge these difference graphs together to generate a merged difference graph. Using this merging approach can reveal the revision history between different versions of an API. For example, in merged difference graph 1500, integrated revision edge 1540 has a combined NewSubNode and DatatypeChange edge attribute, indicating two sequential revisions associated with the metadata object represented by node 1254C. If difference graph 1500 were generated directly based solely on knowledge graphs 1200A and 1200C, the corresponding revision edge linking nodes 1226A and 1254C would only have a NewSubNode edge attribute because the data type change from version 2.5 to version 2.6 of the API would not be revealed.

[0185] In addition, as described below, automatically generated difference maps may sometimes be manually modified, for example, to correct certain errors. The merged difference map can capture such manual corrections. For example, if an error is manually corrected in difference map 1300, such correction will be reflected in merged difference map 1500. On the other hand, if difference map 1500 is directly generated based solely on knowledge graphs 1200A and 1200C, manual corrections made to difference map 1300 will be lost in difference map 1500.

[0186] Example 16 — Example method for manually reviewing a knowledge graph

[0187] In some examples, API providers can view and edit the knowledge graph (including the difference graph) generated by the API registry, such as Figure 16 The high-level flow chart is shown in Figure 1.

[0188] At 1612 , the API provider 1600 may register the new API with the API registry 1620 .

[0189] At 1622 , the API registry 1620 may automatically compute or generate a knowledge graph representation of the newly registered API, for example, according to the method 600 described above.

[0190] Optionally, at 1614, the automatically generated knowledge graph representation of the newly registered API can be presented to API provider 1610, for example, via a graphical user interface. API provider 1610 can review and edit the knowledge graph as needed. For example, API provider 1610 can add annotations to the knowledge graph to explain certain nodes or edges in the knowledge graph. In another example, API provider 1610 can manually modify the knowledge graph if necessary.

[0191] At 1624, the API registry 1620 may check whether there is a predecessor or successor of the newly registered API. For example, the API registry 1620 may search the knowledge graph repository (e.g., 334) to check whether there is a previously stored knowledge graph that represents an older version (i.e., predecessor) or a newer version (i.e., successor) of the API than the newly registered API.

[0192] If the conditional check at 1624 returns yes, the API registry 1620 may proceed to 1626 to calculate or determine a difference graph between the knowledge graph corresponding to the newly registered API and a previously stored knowledge graph (corresponding to a predecessor or successor of the newly registered API), e.g., according to the above-described method 1100. If the conditional check at 1624 returns no, no difference graph is generated.

[0193] Optionally, at 1616, the generated difference graph can be presented to API provider 1610 for review, for example, via a graphical user interface. API provider 1610 can review and edit the difference graph as needed. For example, API provider 1610 can add annotations to the difference graph to explain the reasoning behind some changes between two different versions of the API. In another example, API provider 1610 can manually correct some errors in the automatically generated difference graph.

[0194] For example, a metadata object may be renamed between two different versions of an API. As a result, the automatically generated difference graph may incorrectly identify that new nodes have been added to the knowledge graph representing the newer version of the API, and traditional nodes have been deleted from the knowledge graph representing the older version of the API, but such new nodes and deleted traditional nodes actually represent the same attributes. In this case, the API provider 1610 can manually correct the error in the difference graph, for example, by undoing the node deletion (from the older version of the knowledge graph) and the node addition (to the newer version of the knowledge graph), and directly linking the two nodes (representing the same metadata object) in the two knowledge graphs with a revision edge (e.g., with a NameChange edge attribute).

[0195] Example 17 - Example UI for the API Registry

[0196] Figures 17-20 Several example user interfaces are shown through which an API publisher or API subscriber may interface with an API registry (e.g., 120, 220, 320, 520, etc.) It will be understood that the layout of the user interfaces is for illustration purposes only, and any user interface described below may be modified as desired.

[0197] Figure 17An example user interface 1700 is shown through which a user 1710 (e.g., an API publisher named "Provider User 1") can register a new version of an API (e.g., version 2.5). In the depicted example, the user interface 1700 provides a link or reference 1720 (e.g., a URL) to a previous version of the API (e.g., version 2.4) or a predecessor API. The API provider can enter the address or location 1730 of an API specification document (e.g., generated by a Swagger adapter, etc.) corresponding to the new version of the API. The API provider can then trigger (e.g., by clicking a "Calculate" button, etc.) a transformation of the API to generate a knowledge graph representing the API (e.g., using method 600 described above). The generated knowledge graph can be displayed in a display window 1740. The knowledge graph can be arranged (e.g., from left to right, from top to bottom, etc.) to show the hierarchical relationships between nodes. The user can zoom the knowledge graph, for example, by collapsing / hiding or expanding / showing the child nodes of any given node. The user can also zoom, pan, and / or otherwise navigate different parts of the knowledge graph within the display window 1740. The corresponding metadata and schematic data values ​​of the API can be shown in another window 1750. For example, the user can click on various nodes of the knowledge graph to view the metadata represented by the node. In some examples, the user can edit the knowledge graph, for example by annotating and / or changing the information presented in window 1750.

[0198] Figure 18Another example user interface 1800 is shown, through which a user 1810 (e.g., an API publisher named "Provider User 1") can generate a difference graph based on two knowledge graphs representing two different versions of an API. In the depicted example, the user can select a link or reference 1820 (e.g., a URL) to a previous version of the API (e.g., version 2.4) or a predecessor API, and another link or reference 1830 (e.g., another URL) to an updated version of the API (e.g., version 2.5) or a successor API. The user can then trigger the calculation of the difference graph based on the two knowledge graphs representing the two versions of the API. The generated difference graph can be displayed in a display window 1840. In some examples, the revision edges in the difference graph can be highlighted. Similarly, the user can zoom the difference graph, for example, by folding / hiding or expanding / showing the child nodes of any given node, and the user can also zoom, pan and / or otherwise browse different parts of the difference graph within the display window 1840. Information for the revision edges can be shown in another window 1850. For example, a user can click on any revision edge to view information related to the changes between the two nodes connected by the revision edge. In some examples, a user can edit the difference graph, for example, by annotating and / or changing the information presented in window 1850. For example, as described above, a user can modify a revision edge that is deemed incorrect.

[0199] Figure 19 Another example user interface 1900 is shown through which a user 1910 (e.g., an API subscriber named "Consumer User 1") can create a subscription profile (or subscription configuration file). In the depicted example, the user can select a link or reference 1920 (e.g., a URL) to a specific version of the API (e.g., version 2.4). The user's subscription profile can be shown in an API profile window 1930. The displayed subscription profile can list metadata objects under all nodes of the knowledge graph representation of the API, for example, in the form of Figure 19 In other examples, the subscription profile can be presented in a knowledge graph format (e.g., similar to Figure 171750 ). The user can select individual nodes (e.g., by checking a box under the "Child" column and next to the corresponding metadata object). In some examples, the API registry can provide one or more default subscription profiles that the user can use. For example, a subscription profile can have a default setting in which all nodes are selected or deselected. As another example, a default subscription profile can have nodes of a particular type selected while leaving other nodes deselected. For each selected node (e.g., node 1932 representing the metadata object ActionCode), all possible change conditions associated with the selected node (e.g., initial node creation, node update, node deletion, node modification, etc.) can be displayed in the node description window 1940. The user can select which change conditions associated with the selected node are of interest. The change conditions selected by the user can be displayed on another window 1950. In some examples, the default subscription profile can pre-select or deselect certain change conditions. Once saved to the user's subscription profile, the user has subscribed to the selected change conditions associated with each selected node. As a result, the user is notified if and only if the API change satisfies one of the user-selected change conditions for the selected node. For example, if the user's subscription profile specifies that the user is only interested in any data type changes on one specific child node, then the user will receive a notification if the child node has a data type change, but will not be notified if the child node only has a name change.

[0200] Figure 20 Another example user interface 2000 is shown through which a user 2010 (e.g., an API subscriber named "Consumer User 1") can compare two different versions of an API. In the depicted example, the user can select a link or reference 2020 (e.g., a URL) to a previous version (e.g., version 2.4) or a predecessor API of the API, and another link or reference 1830 (e.g., another URL) to an updated version (e.g., version 2.5) or a successor API of the API. In some examples, the predecessor API can be an API that the user is currently using, and the successor API can be a new version of the API that the user is considering upgrading to. The user can manually trigger a compatibility test between two versions of the API. For example, the user interface 2000 can appear after the user wants to know the impact of upgrading to a new version of the API, for example, by clicking Figure 19 An “Update to New Version” button 1922 in the user interface 1900 of .

[0201] In the background, a difference graph can be calculated based on two knowledge graphs representing the predecessor API and the successor API, respectively. The difference graph can be compared with the user's subscription profile to identify API changes (e.g., revision edges and nodes associated with the revision edges) that meet the change conditions specified in the user's subscription profile. These identified API changes (also referred to as "profile-compatible API changes") can be a subset of all API changes represented by the difference graph. For example, some API changes that the user is not interested in (e.g., do not meet the change conditions specified in the user's subscription profile) will not be identified as profile-compatible API changes.

[0202] As shown, metadata objects related to profile-compatible API changes can be displayed in windows 2040 and 2050, based on which the user can view the compatibility of the API according to the user's subscription profile. Window 2040 can display metadata objects represented by nodes of the knowledge graph representing the predecessor API, and window 2050 can display metadata objects represented by corresponding nodes of the knowledge graph representing the successor API. Window 2050 can also display the type of change (e.g., under the "Transformation" column) based on the attributes of the revision edges (e.g., NewNode edges indicate "Addition" transformations, DeletedNode edges indicate "Deletion" transformations, DatatypeChange edges indicate "Type Change" transformations, etc.). Although windows 2040 and 2050 show metadata in a tabular format, in other examples, profile-compatible API changes can be shown in a graphical format. For example, revision edges and nodes in a difference graph associated with profile-compatible API changes can be shown in windows 2040 and 2050. Thus, the information displayed in windows 2040 and 2050 is a customized comparison (between the predecessor API and the successor API) tailored to the user's subscription profile.

[0203] Additional details of each profile-compatible API change can be further listed in another window 2060. The user can also choose to accept or reject each profile-compatible API change and add comments (e.g., to explain the reasons for acceptance or rejection). In some examples, the user interface 2000 can be connected to a ticketing system. Once confirmed (e.g., by clicking a "Save" button), the user's acceptance / rejection of the profile-compatible API change along with the comments can automatically trigger the ticketing system to generate a ticket, which can be automatically sent to the API publisher for review. Based on the received ticket, the API publisher can access the impact of publishing the new API on API subscribers.

[0204] Example 18 - Example method to run a mock on the API registry

[0205] The API registry described here allows both API publishers and API subscribers to run simulations.

[0206] For example, an API publisher can run a simulation on an API registry to quantify how many active users (e.g., API subscribers) are interested in or still use a particular metadata object of the API by searching the subscription profiles stored on the API registry. Similarly, by analyzing the stored subscription profiles, the API publisher can also assess the impact of a particular change on the API (e.g., the API provider can determine how many API subscribers will receive notifications triggered by a particular API change). The API publisher can use such simulation results to determine and / or adjust the API development / release / support strategy accordingly. In addition, the API provider can receive feedback about API changes (e.g., through a ticketing system associated with the API registry) and can react to the received feedback as described above.

[0207] On the other hand, API subscribers can run simulations to determine the technical impact of upgrading or downgrading an API via a subscription profile. As described above, API subscribers can run compatibility tests between two versions of an API. API subscribers can also conveniently view, record, and analyze the revision history of an API through a graphical user interface. In addition, API subscribers can also provide feedback to API publishers (e.g., through a ticketing system associated with the API registry).

[0208] Example 19 - Example computing system supporting intelligent API updates

[0209] Figure 21 The overall block diagram of an example computing system 2100 supporting smart API updates is shown. The system 2100 includes an API registry 2120 and an update platform 2110. Although the API registry 2120 and the update platform 2110 are Figure 21 21. Although depicted as two separate parts, in some examples, API registry 2120 and update platform 2110 may be integrated, as described below.

[0210] The API registry 2120 may be similar to Figure 33. For example, the API registry 2120 may include a registration unit 2130, a transformation unit 2140, and a subscription unit 2150. In some examples, the registration unit 2130 may include a knowledge graph storage device (similar to the knowledge graph storage device 334) that stores multiple knowledge graphs representing different versions of the API, and the transformation unit 2140 may include a transformation storage module (similar to the transformation storage module 344) that stores multiple difference graphs representing changes between different versions of the API.

[0211] The update platform 2110 may include an enhanced general annotation system 2160 , a central storage 2170 (also referred to as a central repository), an interpreter platform 2180 (also referred to as a type-specific interpreter), and an action recommendation service 2190 .

[0212] As further described below, the enhanced general annotation system 2160 allows tenants or users of the update platform 2110 (e.g., API providers, platform administrators, third-party software developers, etc.) to annotate revision edges of one or more difference graphs. Such annotations can include defining standard and / or custom actions for implementing the specific API changes represented by the corresponding revision edges. In some examples, standard actions can be defined based on general standard functions that are independent of the programming language. In some examples, the enhanced general annotation system 2160 can be integrated with the API transformation unit 2140.

[0213] Annotations (e.g., defined standards and / or custom actions) can be stored in a code repository in the central storage 2170. In some examples, the central storage 2170 can be integrated with a knowledge graph storage associated with the registration unit 2130 and a transformation storage module associated with the API transformation unit 2140. In this case, the central storage 2170 can also store knowledge graphs and difference graphs created by different tenants (e.g., API providers, API consumers, third-party software developers or consultants, etc.).

[0214] Interpreter platform 2180 can be configured to explain the annotations made to the revision edge of the difference graph. This explanation can automatically convert predefined standard and / or customized actions into function packages written in a specific programming language. In some examples, interpreter platform 2180 also allows some users (e.g., API providers, platform administrators, third-party software developers, etc.) to modify the automatically generated function packages.

[0215] API consumer 2102 can interact with update platform 2110 to perform intelligent API updates. For example, action recommendation service 2190 can recommend software or function packages that can be installed and implemented to API consumer 2102 for specific API updates.

[0216] Example 20 - Example overall process and method for intelligent API updates

[0217] Figure 22 is a flow diagram depicting an example process 2200 for performing smart API updates.

[0218] At 2210 , as described above, the API registry may notify registered API consumers that the API has a newer version and prompt the API consumers to update the API.

[0219] At 2220, the API consumer may configure parameters for implementing the API update. For example, the API consumer may select a source version (e.g., the current version of the API running on the API consumer's computing system), a target version (e.g., a new version of the API available for upgrade), and a target programming language to be used by the API consumer.

[0220] At 2230, the update platform can recommend to the API consumer (e.g., via action recommendation service 2190) what action to take. In some examples, the update platform can generate a list of change recommendations. For example, the update platform can recommend that the API consumer download an "old API to new API" adapter and / or download "old API to new API" change source code, etc. In some examples, the "old API to new API" adapter can be configured to retrieve annotations stored in a code repository (e.g., defining standard and / or custom actions).

[0221] At 2240, the API consumer may use the change recommendation list as a basis for implementing the API update. For example, the API consumer may select and implement some recommended actions, such as installing an "old API to new API" adapter, viewing the "old API to new API" change source code, etc. In some examples, installing the "old API to new API" adapter may automatically install a function package written in the target programming language and implement the API change to update the API from the source version to the target version.

[0222] Optionally, at 2240, the API consumer may choose to make his API update solution available to other API consumers, for example, by publishing or recording (e.g., in central storage 2170) what actions he has taken to implement the API update. In some examples, the information or feedback provided by many API consumers may be aggregated, summarized, and analyzed to obtain "wisdom of the crowd," which the update platform may further use to generate smarter recommendations to future API consumers on how to update the API between different API versions.

[0223] Figure 23is a flow chart of an example overall method 2300 for performing smart API updates and may be, for example, Figure 23 Executed by computing system 2100.

[0224] At 2310 , a user (eg, API consumer 2102 ) may specify source and target versions of the API as well as a target programming language (eg, Java, Python, etc.).

[0225] At 2320, a difference graph can be retrieved (e.g., from central storage 2170 or a transformation storage module). The difference graph can connect a source knowledge graph representing a source version of the API to a target knowledge graph representing a target version of the API. As described above, the difference graph can include one or more revision edges representing changes between the source and target versions of the API.

[0226] At 2330 , the user may install one or more function packages written in a target programming language and associated with one or more revision edges.

[0227] Then, at 2340 , the user may run one or more function packages to update the API from the source version to the target version.

[0228] Example 21 - Example Enhanced Annotation of Revision Edges in a Difference Graph

[0229] As described above, a difference graph can include one or more revision edges (e.g., PropertyChange edges, DeletedNode edges, NewNode edges, etc.) that represent API changes between two different versions of an API. The properties of the revision edges can be defined by the ontology of the difference graph. In some examples, the revision edges in the difference graph can be further annotated (e.g., using the enhanced general annotation system 2160) so that the revision edges can be linked to predefined actions or functions that are configured to implement the corresponding changes to the API represented by those revision edges.

[0230] Figure 24 2. 4. 2. 4. 2. 6 ...

[0231] For example, a selected revision edge 2430 may be annotated by assigning an API change identifier, an action identifier, and one or more action parameters to the revision edge. The API change identifier may indicate that the API has changed from a source version to a target version (e.g., the API change identifier may be the string "API 2.4 => API 2.6," etc.). The action identifier may indicate the action or function 2440 defined for the revision edge. The one or more action parameters may specify inputs to the action or function 2440. Other revision edges may be annotated similarly.

[0232] Example 22 - Example standard actions and custom actions

[0233] As described herein, one or more standard actions (or standard functions) may be defined for implementing a specific change to an API represented by a corresponding revision edge. In some examples, the standard actions may be language independent.

[0234] In some examples, one or more standard actions can be defined based on a generic standard action (or generic standard function). A generic standard action is a generic representation of one or more standard actions. For example, a generic standard action can define variable input types, variable return types, and parameter structures for one or more standard functions. A parameter structure can represent a variable set of parameter names and parameter values ​​that serve as input parameters to one or more standard actions. Therefore, a generic standard action can be considered a generic function based on which one or more standard actions can be defined.

[0235] As an example, Figure 25 A generic standard action 2500 implemented in Java is shown. In this example, the generic standard action 2500 defines a generic method "standardAction" with two parameters: "InputType", which is a placeholder for the node type in the source API, and "ReturnType", which is a placeholder for the node type in the target API. The generic method "standardAction" also provides a generic constructor "Map<String, String>".<String,Object> ", which can be used to specify action parameters including parameter name ("String") and corresponding parameter value ("Object"). It is worth noting that Figure 25 This shows only one of many options for implementing generic standard actions in Java. In typed languages ​​like Java, a generic representation of "standardAction" is recommended but not strictly required (it can be implementation specific). In untyped languages ​​like JavaScript or Python, the representation of generic standard actions can be omitted.

[0236] As described herein, each standard action may be mapped to two or more target programming languages.To illustrate, let us assume a standard action for rounding up a value. Figure 26 Two example implementations of such a standard action are depicted: a function "RoundUpStandardAction" 2610 written in Java, and another function "RoundUpStandardAction" 2620 written in Python.

[0237] The standard action 2610 is defined based on the general standard action 2500 described above, where the data types of both "InputType" and "ReturnType" are specified as "double (double precision floating point number)". It is worth noting that the round-up operation does not require additional input parameters. Therefore, in this example, the general construct "Map<String,Object> " can remain unspecified. Based on the same general standard action 2500, other standard actions (e.g., rounding down, type conversion, date conversion, value passing, etc.) can be similarly implemented. For some standard actions, action parameters need to be specified. For example, in order to implement a standard action for type conversion, the general construct "Map<String,Object> "Requires two action parameters to specify the source data type and the target data type respectively.

[0238] On the other hand, because Python is an untyped language, standard actions 2620 can be implemented without a generic representation.

[0239] In some examples, each defined standard action can be maintained via a low-code / no-code user interface, such as Figure 27 27. In this example, a standard action is defined to implement a data type change from an integer to a string (e.g., a standard type conversion action that changes data from data type "int" to data type "char"). Such standard actions can be maintained via a drop-down menu 2710. By selecting a standard action ("Cast" in the depicted example), a submenu 2720 can be displayed showing the source data type (e.g., from "int") and the target data type (e.g., to "char").

[0240] In some examples, standard actions can be defined by different parties. For example, an API or platform provider can provide multiple standard actions. Any platform tenant, such as third-party software developers (also known as partners) and / or API consumers, can define standard actions. In some examples, the API or platform provider can access the standard actions defined by each tenant. In some examples, standard actions can be moved or shared between tenants (third-party software developers can ship standard actions to API consumers). Therefore, collaboration between different parties is possible. In some examples, third-party software developers can define their own standard actions that are only visible to them and their customers.

[0241] In some examples, users (e.g., through API providers, third-party developers, API consumers, etc.) can define custom actions to implement some more complex transformation functions that may require detailed source code or a low-code / no-code editor. Custom actions are actions that are not available as a user interface (e.g., Figure 27 ) as they can be specific to a limited use case. For example, some revision edges can be annotated so that they link to custom actions that require more extensive or very specific (non-universal) coding (i.e., usability in only one programming language).

[0242] In some examples, a user can define a custom action using a default domain-specific language (DSL) that contains a limited set of operations implemented in all programming languages ​​(e.g., addition, subtraction, variable declaration, etc.). The DSL contains basic programming constructs with interpretations in any programming language. In other examples, if the DSL is insufficient, the user can create a programming language-specific custom action that is limited to a previously selected programming target language. Therefore, the custom action is then only available for that language and may have to be rewritten for other languages.

[0243] Some example custom actions may be defined to implement functions such as shortening a data type (e.g., string 80 to string 50), business-related changes (e.g., introducing new tax parameters), changing the first letter from "D" to "I" and discarding leading zeros, etc. In general, for each customer action, action parameters may be required.

[0244] As an example, Figure 28A user interface for defining custom actions is shown. In this example, a custom action is implemented to shorten a string. Through parameter list 2810, the user can specify parameters for the custom action (e.g., parameter A_input1 can indicate the number of characters to be retained in the string after the shortening operation). Through the no-code / low-code editor 2820, the user can specify high-level operations (e.g., using a DSL) to shorten the string. The actual source code 2830 for the string shortening function can be automatically generated based on the high-level operations specified by the user.

[0245] Example 23 - Example language specific function explanation

[0246] In practice, each API consumer may have its own specific system and development landscape. As a result, different API consumers may have different software components and use different programming languages. To further reduce the effort of API upgrades, the revision edges annotated in the difference graph can be interpreted as different programming languages, such as Python, C++, Java, etc. This interpretation can be done by Figure 29 2910 and generates a package of functions 2960 (also referred to as a "reconciliation function") as output. The package of functions 2960 is converted from standard and / or custom actions associated with the revision edges annotated in the difference graph 2910, but is written in a specific or target programming language. In other words, the package of functions 2960 includes software code (written in a specific programming language) for implementing the API changes represented by the revision edges in the difference graph 2910. The interpretation platform 2900 may be Figure 21 An example embodiment of the interpreter platform 2180.

[0247] like Figure 29 As shown, the interpretation platform 2900 may include a function generator 2930 and an adjuster 2940. The function generator 2930 may include multiple adapters 2932 (e.g., a Java adapter, a Python adapter, a C++ adapter, etc.) that are configured to translate or convert a function written in one programming language into another programming language. By providing a bridge between the two languages, each adapter 2932 can map the syntax, data types, and constructs of one language to the equivalent elements of another language. Therefore, by providing multiple adapters 2932, a standard or customer action can be converted into multiple function packages 2960 written in different programming languages.

[0248] In some examples, the API consumer can specify a target programming language in the client profile 2920, based on which an appropriate adapter can be selected 2932. For example, if the API consumer specifies Python as the target programming language, a Python adapter can be selected to convert standard and / or custom actions associated with revision edges of annotations (which can be written in a language other than Python) into a function package 2960 written in Python.

[0249] Optionally, a user 2950 (e.g., an API provider, a platform administrator, a third-party software developer, etc.) can manually modify and / or annotate the software code generated by the adapter 2932 before rolling it out in production. For example, the adaptor 2940 can have a user interface 2942 that provides a no-code / low-code environment for the user 2950 to view, edit, and / or annotate the software code generated by the adapter 2932.

[0250] Example 24 - Sample data storage platform supporting intelligent API updates

[0251] Figure 30 An example central storage system 3000 is depicted that can be used as a group storage for intelligence that supports intelligent API updates. The central storage system 3000 can be Figure 21 An example of central storage 2170 is depicted in .

[0252] As shown, the central storage system 3000 may include an API storage 3010 (similar to the knowledge graph storage 334), which is configured to store knowledge graphs corresponding to different versions of the API. The central storage system 3000 also includes a difference graph storage 3020 (similar to the transformation storage module 344), which is configured to store difference graphs created by various parties (e.g., API providers, API consumers, third-party software developers, etc.). For example, an API provider may provide a set of difference graphs corresponding to a list of API updates, and an API consultant may provide another set of difference graphs corresponding to the same or different list of API updates.

[0253] As described above, the difference graph can be annotated by defining standard and / or custom actions for implementing specific API changes represented by corresponding revision edges in the difference graph. The central storage system 3000 may include a code repository 3040 that is configured to store standard and / or custom actions linked to corresponding revision edges in the difference graph. The annotation of the difference graph can be performed by different parties (e.g., API providers, API consumers, third-party software developers, etc.). In this way, the standard and / or custom actions stored in the code repository 3040 can be contributed by different parties. In other words, different parties can provide different solutions for the same API update (e.g., from API version 1.7 to API version 1.8).

[0254] Optionally, the central storage system 3000 may also include an adjustment storage 3030 configured to store the adjusted difference map. Similarly, the adjusted difference map may be created by different parties (e.g., an API provider, an API consumer, a third-party software developer, etc.). The adjusted difference map may include specific adjustments made by the user to the difference map. In some examples, the adjusted difference map includes adjustments made by the user to the adapter 2932, for example, by Figure 29 The function package 2960 generated by the adjuster 2940 performs editing and / or annotation.

[0255] Example 25 - Example diff chart recommendation for smart API updates

[0256] Figure 31 An example user interface 3100 is shown through which a user (e.g., an API consumer) can receive notifications of available API updates (e.g., through the API registry described above). In addition, by scanning the central storage system 3000, the update platform 2110 can display and recommend available solutions 3130 (e.g., a difference map with annotations) for a particular API update 3110 and a list of providers 3120 for API update solutions. The recommendation of API update solutions can be, for example, provided by Figure 21 The action recommendation service 2190 is executed.

[0257] Additionally, for each listed API update solution, a direct link is provided to the user to take action to implement the API update. As an example, after the user clicks the arrow button corresponding to the solution provided by SAP to update the S / 4 Cost Center API from version 1.4 to version 1.7, the user may be presented with Figure 32 The pop-up window 3210 shown asks the user to confirm the selection of the API update solution. If the user confirms the selection, the difference graph corresponding to the annotation of the S / 4 cost center API update from version 1.4 to version 1.7 can be retrieved from the difference graph storage 3020 and used to update the S / 4 cost center API.

[0258] In some examples, there may be multiple solutions developed by different parties for implementing the same API update. For example, third-party developers or API consumers can build their own difference maps and publish / provide them as "unofficial" API update solutions via the central storage system 3000. Other users can use these solutions and vote on them. The vote counts can be stored in the central storage system 3000 and used to rank these solutions in the user interface.

[0259] As an example, Figure 33 A user interface 3300 is shown that lists four annotated difference graphs created by four different parties for updating a cost center API from version 1.4 to version 1.7. Each difference graph can have revision edges linked to standard and / or custom actions defined by the corresponding party. A user can select a specific difference graph from the list for implementing the cost center API update.

[0260] To facilitate user selection, the listed difference graphs may be ranked based on the count of user selections (or votes) of the difference graphs to update the API, the provider of the difference graphs, or both. For example, Figure 33 It is shown that the difference map provided by SAP has been selected (or voted) for API update by 50 users, and the difference map provided by A GmbH has been selected (or voted) for API update by 80 users. The difference map provided by SAP may be ranked higher than the difference map provided by A GmbH because SAP is the provider of the cost center API.

[0261] In some cases, the API provider may not have uploaded a complete out-of-the-box solution for every possible API update operation in the central storage system 3000 (for example, the API provider may provide a difference map for updating the API from version 1.2 to version 1.3, but not for updating the API from version 1.1 to version 1.3). In these cases, the system can still help users easily update the API by suggesting alternative solutions. For example, users can choose an "unofficial" API update solution provided by a third-party developer.

[0262] In some cases, the difference graph for a specific API update may not be found in the central storage system 3000. In this case, the system can help the user build the desired difference graph by combining some available difference graphs. Figure 34An example is shown in , which shows four different versions of an API (e.g., API 1.4, API 1.5, API 1.6, and API 1.7). In this example, there are no difference graphs available for directly updating API 1.4 to API 1.7. However, there are existing difference graphs (also called sub-change graphs) developed by different parties for implementing incremental API updates, such as two sub-change graphs A and B for updating API 1.4 to API 1.5, two sub-change graphs C and D for updating API 1.5 to API 1.6, one sub-change graph E for updating API 1.5 to API 1.7, and one sub-change graph F for updating API 1.6 to API 1.7.

[0263] In some examples, a graph algorithm can be applied to calculate all paths for updating an API from version 1.4 to version 1.7. For example, the graph algorithm can determine six different paths for updating API 1.4 to API 1.7: (A, C, F), (A, D, F), (A, E), (B, C, F), (B, D, F), and (B, E). For each path, the sub-change graphs involved can be concatenated or combined, as described above with reference to Figure 14-15 As described above, to generate a desired diff graph for updating API 1.4 to API 1.7. In some examples, the different paths generated by the graph algorithm can be ranked based on various criteria, such as the number of sub-change graphs involved in the path (e.g., shortest paths are ranked higher), the providers of the sub-change graphs (e.g., some providers can be ranked higher and some providers can be blacklisted), the number of user votes on the sub-change graphs, programming language availability, etc.

[0264] For example, Figure 35 A user interface 3500 is shown that provides a list of available sub-change graphs that can be combined to generate a desired difference graph for updating a cost center API from version 1.4 to version 1.7. The available sub-change graphs can be ranked, for example, based on the provider and / or the number of votes received. In this example, a user can select three sub-change graphs (API 1.4 to API 1.5 provided by A GmbH, API 1.5 to API 1.6 provided by SAP, and API 1.6 to API 1.7 provided by SAP) to build a difference graph for updating API 1.4 to API 1.7.

[0265] Example 26 - Example action recommendation for smart API updates

[0266] After the user selects (or constructs) an annotated difference graph for an API update, the standard and / or custom actions associated with the revision edges of the annotated difference graph can be retrieved from the code repository. As described above, the retrieved standard and / or custom actions can be automatically converted (e.g., by interpreting platform 2900) into corresponding function packages written in the user-specified target programming language. The converted function packages can then be installed and executed on the user's system to update the API.

[0267] An annotated difference graph may have many revision edges. In some examples, not all revision edges are annotated by the provider of the difference graph. For example, the standard actions for some revision edges may be missing in the annotated difference graph. In this case, recommendations may be provided to the user to select appropriate standard actions for those revision edges. For example, Figure 21 The action recommendation service 2190 performs action recommendations for revising edges.

[0268] In some examples, a group proposal method can be used to recommend standard actions for revision edges that are not annotated in the difference graph. Specifically, the action recommendation service can search the central storage system to find other standard actions that can implement the API change represented by the unannotated revision edge.

[0269] For example, assume that the revision edge representing the change of the metadata object "BusinessPartnerID" in the difference graph A representing the cost center API update between version 1.4 and version 1.7 is annotated (i.e., has no linked standard action). The same "BusinessPartnerID" change can be represented by an annotated revision edge in another difference graph B representing the cost center API update between version 1.4 and version 1.6 (Note: the providers of difference graph A and difference graph B can be the same or different). In this case, the standard action linked to the annotated revision edge in difference graph B can be recommended to the user. In other words, if another user annotates that "BusinessPartnerID" changes between API versions 1.4 and 1.6, then if the change operation (revision edge) and the metadata object involved are the same, then the annotated change can also be used to update the API version from 1.4 to 1.7.

[0270] As another example, assume that a change in the metadata object "BusinessPartnerID" is a specific type change (e.g., from INT to CHAR). If the specific type change is also represented by other annotated revision edges in one or more difference graphs (which may represent the same API update or different API updates), then standard actions linked to those annotated revision edges can also be recommended to the user. For example, if the revision edge representing a change in another metadata object "HomeSystemID" also represents the same type change, then the standard action used to implement the "HomeSystemID" change can also be used to implement the "BusinessPartnerID" change because the underlying operation (e.g., type change) is the same.

[0271] In some examples, the group proposal method described above can be implemented in a waterfall model so that recommended actions can be prioritized or given different weights. For example, an action annotated with the same change operation (revision edge) for the same metadata object in the same API but with different update versions can be given a higher priority than an action annotated with the same change operation (revision edge) for different metadata objects in the same API (with the same or different update versions). As another example, an action annotated with the same change operation (revision edge) for different metadata objects in the same API can be given a higher priority than an action annotated with the same change operation (revision edge) for different metadata objects in different APIs.

[0272] In the event that the group proposal method described above does not find any actions stored in the central storage system that can perform the same change operation on an unannotated revision edge, the action recommendation service can propose a default action, which is a predefined or hard-coded proposal for certain default cases. For example, the default action for a data type change from CHAR(10) to CHAR(20) could be a null function (i.e., do nothing); the default action for a data type change from INT to DOUBLE could be the predefined standard function CAST(int, double). In other words, the change operation for an unannotated revision edge can be mapped to some default or predefined standard action.

[0273] Figure 36 is an example user interface 3600 showing a difference graph 3610 selected by a user. Figure 183600 can display all revision edges 3620 (and related information) of the difference graph 3610. Unlike the user interface 1800, the user interface 3600 provides additional controls that allow the user to select an action for implementing the API change corresponding to the revision edge 3620. Specifically, for each selected revision edge 3620, the update platform 2110 can recommend an action for implementing the specific API change represented by the selected revision edge 3620.

[0274] For example, after the user selects the revision edge "Transformation - Type Change 1", the user can click the button "Load Proposals" to view a list of recommended standard actions that can implement the type change corresponding to the selected revision edge, such as Figure 37 as shown in the pop-up window 3710. Figure 37 The list of recommended standard actions shown in can be generated based on the group proposal method described above. In this example, the update platform finds three standard actions defined by three different providers that are available for the user to download and install. For each recommended standard action, the number of times other users have downloaded (or voted for) it can also be displayed. To facilitate the user's decision on which action to install, the list of available actions can be ranked based on the number of user downloads, the provider of the action, or both.

[0275] Figure 38 An example user interface is shown that shows a default action for an unannotated revision edge that represents a value transfer operation and is predefined by the provider and / or administrator of the update platform (in the event that the above-described group proposal method does not find any action defined by a tenant of the update platform that can perform the same value transfer operation). Figure 39 As shown in another example user interface shown, the provider or administrator of the update platform can maintain the default action library (e.g., add, edit, or delete default actions). In addition, the provider or administrator of the update platform can configure the conditions for recommending default actions to users (e.g., the configuration can allow the default action to be recommended to the user along with other actions found by the group suggestion method).

[0276] Example 27 - Example Advantages

[0277] Many advantages can be achieved through the techniques described herein.

[0278] In one aspect, the knowledge graph representation of APIs described herein is technology agnostic compared to conventional API change management techniques because the knowledge graph representation of APIs has a common ontology that applies to all APIs regardless of the programming language used in the API and / or the adapter used to document the API.

[0279] On the other hand, compared to conventional text-based API specification documents, a knowledge graph representation of an API can provide a conceptually more understandable visualization of the structure of the API, including the hierarchical relationships between different metadata objects embedded in the API.

[0280] On the other hand, using a difference graph, changes between different versions of an API (e.g., reflected by revision edges) can be easily and intuitively identified. The difference graphs can be concatenated to show the incremental revision history between each pair of consecutive versions of an API, and / or merged to show the consolidated changes between two versions of an API that were separated by many intermediate versions of the API.

[0281] In yet another aspect, by subscribing to an API registry and creating a customized subscription profile, a user of the API can receive immediate notifications of API changes (as defined by the subscription profile) that the user is interested in. The user will not be bothered to receive notifications of API changes that are not relevant to the user (e.g., API changes that are outside the scope of the subscription profile).

[0282] In another aspect, by analyzing subscription profiles, API providers can quantitatively determine how many users are using the API, and even how many users are actively using specific metadata objects within the API. API providers can also determine the impact of changing the API. Such analysis can guide the API provider's decision-making process for API development, release, and / or support strategies.

[0283] On the other hand, by subscribing to the API registry and creating a customized subscription profile, users of the API can run simulations to evaluate the effects of upgrading or downgrading the API based on the user's subscription profile (without actually performing the API upgrade or downgrade). Therefore, users can effectively estimate the effort to invest in API version management projects.

[0284] In addition, users of the API can not only receive notifications of relevant API changes in a timely manner, but also easily implement those API changes, even if the user does not have programming skills or technical expertise on the API. Using the update platform described herein, the difference graph can be annotated by linking the revision edge to standard and / or custom actions, and the standard and / or custom actions can implement the corresponding API changes represented by those revision edges. In addition, each tenant of the update platform can publish or provide its own solution (for example, the difference graph of annotations) for different API updates. For each specific API update, the update platform can provide a list of available solutions and rank these solutions based on predefined standards. Therefore, users of the API can simply select a solution from the list to self-implement the API update. Specifically, after the user selects a specific solution, the standard and / or custom actions associated with the difference graph of the annotation can be automatically retrieved. The retrieved actions can also be automatically converted into function packages written in the target programming language specified by the user. These function packages can then be installed on the user's computing system to complete the API update. Furthermore, even in cases where the difference graph is not fully annotated (e.g., some revision edges may not be linked to predefined actions), the update platform can use the wisdom of the crowd (e.g., by searching a central storage system) to recommend appropriate actions for those unannotated revision edges.

[0285] Example 28 - Example Computing System

[0286] Figure 40 An example of a suitable computing system 4000 is depicted in which the described innovations may be implemented. Computing system 4000 is not intended to suggest any limitation as to the scope of use or functionality of the disclosure, as the innovations may be implemented in a variety of computing systems.

[0287] refer to Figure 40 , the computing system 4000 includes one or more processing units 4010, 4015 and memories 4020, 4025. Figure 40 , the basic configuration 4030 is included within the dashed line. Processing units 4010, 4015 can execute computer-executable instructions, such as for implementing methods 600, 1000, 1100, 2300, etc. described in the examples herein. A processing unit can be a general-purpose central processing unit (CPU), a processor in an application-specific integrated circuit (ASIC), or any other type of processor. In a multi-processing system, multiple processing units can execute computer-executable instructions to increase processing power. For example, Figure 40A central processing unit 4010 and a graphics processing unit or co-processing unit 4015 are shown. Tangible memory 4020, 4025 may be volatile memory (e.g., registers, cache, RAM), non-volatile memory (e.g., ROM, EEPROM, flash memory, etc.), or some combination of the two, accessible by the processing units 4010, 4015. Memory 4020, 4025 may store software 4080 implementing one or more innovations described herein in the form of computer-executable instructions suitable for execution by the processing units 4010, 4015.

[0288] Computing system 4000 may have additional features. For example, computing system 4000 may include storage 4040, one or more input devices 4050, one or more output devices 4060, and one or more communication connections 4070, including input devices, output devices, and communication connections for interacting with a user. An interconnection mechanism (not shown), such as a bus, controller, or network, may interconnect the components of computing system 4000. Typically, operating system software (not shown) may provide an operating environment for other software executed in computing system 4000 and coordinate the activities of the components of computing system 4000.

[0289] Tangible storage 4040 may be removable or non-removable and include magnetic disks, magnetic tapes or cartridges, CD-ROMs, DVDs, or any other medium that can be used to store information in a non-transitory manner and that can be accessed within computing system 4000. Memory 4040 may store instructions for software 280 implementing one or more innovations described herein.

[0290] The input device 4050 may be an input device such as a keyboard, a mouse, a pen or trackball, a voice input device, a scanning device, a touch device (e.g., a touchpad, a display, etc.), or another device that provides input to the computing system 4000. The output device 4060 may be a display, a printer, a speaker, a CD burner, or another device that provides output from the computing system 4000.

[0291] Communication connection 4070 can enable communication with another computing entity via a communication medium. The communication medium can carry information such as computer-executable instructions, audio or video input or output, or other data in a modulated data signal. A modulated data signal is a signal that has one or more of its characteristics set or changed in a manner that encodes the information in the signal. By way of example and not limitation, the communication medium can utilize electrical, optical, RF, or other carrier waves.

[0292] Innovations can be described in the context of computer-executable instructions (such as those included in program modules) being executed in a computing system on a target real or virtual processor (e.g., which ultimately executes on one or more hardware processors). Typically, program modules or components can include routines, programs, libraries, objects, classes, components, data structures, etc. that perform specific tasks or implement specific abstract data types. In various embodiments, the functionality of program modules can be combined or split between program modules as needed. Computer-executable instructions for program modules can be executed within a local or distributed computing system.

[0293] For presentation purposes, the detailed description uses terms such as "determine" and "use" to describe computer operations in a computing system. These terms are high-level descriptions of operations performed by a computer and should not be confused with actions performed by a human. The actual computer operations corresponding to these terms vary depending on the implementation.

[0294] Example 29 - Computer Readable Medium

[0295] Any computer-readable medium herein may be non-transitory (e.g., volatile memory such as DRAM or SRAM, non-volatile memory such as magnetic storage devices, optical storage devices, etc.) and / or tangible. Any storage action described herein may be implemented by storing in one or more computer-readable media (e.g., computer-readable storage media or other tangible media). Anything described as stored (e.g., data created and used during an embodiment) may be stored in one or more computer-readable media (e.g., computer-readable storage media or other tangible media). Computer-readable media may be limited to embodiments that do not consist of signals.

[0296] Any method described herein can be implemented by computer-executable instructions in (e.g., stored on, encoded on, etc.) one or more computer-readable media (e.g., computer-readable storage media or other tangible media) or one or more computer-readable storage devices (e.g., memory, magnetic storage, optical storage, etc.). Such instructions can cause a computing device to perform the method. The techniques described herein can be implemented in various programming languages.

[0297] Example 30 - Example Cloud Computing Environment

[0298] Figure 41An example cloud computing environment 4100 is depicted in which the described techniques may be implemented, including, for example, the systems disclosed above and other systems herein. Cloud computing environment 4100 may include cloud computing services 4110. Cloud computing services 4110 may include various types of cloud computing resources, such as computer servers, data repositories, networking resources, and the like. Cloud computing services 4110 may be centrally located (e.g., provided by a data center of an enterprise or organization) or distributed (e.g., provided by various computing resources located in different locations (such as different data centers) and / or located in different cities or countries).

[0299] Cloud computing services 4110 can be utilized by various types of computing devices (e.g., client computing devices), such as computing devices 4120, 4122, and 4123. For example, computing devices (e.g., 4120, 4122, and 4124) can be computers (e.g., desktop or laptop computers), mobile devices (e.g., tablet computers or smartphones), or other types of computing devices. For example, computing devices (e.g., 4120, 4122, and 4124) can utilize cloud computing services 4110 to perform computing operations (e.g., data processing, data storage, etc.).

[0300] In practice, cloud-based, on-premises, or hybrid scenarios can be supported.

[0301] Example 31 - Example Implementation

[0302] Although the operations of some methods in the disclosed methods are described in a specific sequential order for ease of presentation, this description encompasses rearrangement unless the specific language set forth herein requires a specific ordering. For example, operations described sequentially may in some cases be rearranged or performed simultaneously.

[0303] As used in this application and in the claims, the singular forms "a," "an," and "the" include plural referents unless the context clearly dictates otherwise. Additionally, the term "includes" means "comprises." Furthermore, "and / or" means "and" or "or," as well as "and" and "or."

[0304] Example 32 - Example Implementation

[0305] Any one of the following example embodiments may be implemented.

[0306] Example 1. A computer-implemented method comprising: specifying a source version and a target version of an application programming interface (API) and a target programming language; retrieving a difference graph connected from a source knowledge graph representing the source version of the API to a target knowledge graph representing the target version of the API, wherein the difference graph includes one or more revision edges representing changes of the API between the source version and the target version; installing one or more function packages written in the target programming language and associated with the one or more revision edges; and running the one or more function packages to update the API from the source version to the target version.

[0307] Example 2. The method according to Example 1 further includes: deriving the one or more function packages from one or more standard functions linked to the one or more revision edges, wherein the one or more standard functions are written in a language different from the target programming language.

[0308] Example 3. The method of Example 2, further comprising defining the one or more standard functions for implementing the change to the API represented by the corresponding revision edge.

[0309] Example 4. A method according to Example 3, wherein the one or more standard functions are defined based on a general standard action, wherein the general standard action defines the variable input type, variable return type and parameter structure of the one or more standard functions, wherein the parameter structure represents a variable set of parameter names and parameter values ​​as input parameters of the one or more standard functions.

[0310] Example 5. The method according to any one of Examples 2-4 further includes annotating the one or more revision edges, wherein the annotation includes assigning an API change identifier, an action identifier, and one or more action parameters to at least one revision edge, wherein the API change identifier indicates the API change from the source version to the target version, the action identifier indicates a standard function for the at least one revision edge, and the one or more action parameters specify inputs to the standard function.

[0311] Example 6. The method of any of Examples 2-5, wherein the installing comprises retrieving the one or more standard functions from a code repository.

[0312] Example 7. The method according to any one of Examples 2-6 further includes: generating, for the selected revision edge, a list of available standard functions suitable for implementing changes to the API represented by the selected revision edge; and selecting a target standard function from the list of available standard functions, wherein the installation includes downloading the target standard function.

[0313] Example 8. The method of Example 7, further comprising ranking the list of available standard functions based on user download counts of the available standard functions, providers of the available standard functions, or both.

[0314] Example 9. A method according to any one of Examples 1-8, wherein the retrieved difference graph is selected from a plurality of difference graphs connected from the source knowledge graph to the target knowledge graph, wherein the plurality of difference graphs include corresponding revision edges, wherein the plurality of difference graphs are ranked based on a count of a user selecting the plurality of difference graphs to update an API, a provider of the plurality of difference graphs, or both.

[0315] Example 10. A method according to any one of Examples 1-9, wherein at least one of the function packages is configured to change the data type of a metadata object from the source version of the API to the target version of the API.

[0316] Example 11. A computing system comprising: a memory; one or more hardware processors coupled to the memory; and one or more computer-readable storage media storing instructions that, when loaded into the memory, cause the one or more hardware processors to perform operations, the operations comprising: specifying a source version and a target version of an application programming interface (API) and a target programming language; retrieving a difference graph connected from a source knowledge graph representing the source version of the API to a target knowledge graph representing the target version of the API, wherein the difference graph includes one or more revision edges representing changes to the API between the source version and the target version; installing one or more function packages written in the target programming language and associated with the one or more revision edges; and running the one or more function packages to update the API from the source version to the target version.

[0317] Example 12. A system according to Example 11, wherein the operation further includes deriving the one or more function packages from one or more standard functions linked to the one or more revision edges, wherein the one or more standard functions are written in a language different from the target programming language.

[0318] Example 13. The system of example 12, wherein the operations further comprise defining the one or more standard functions for implementing the change to the API represented by the corresponding revision edge.

[0319] Example 14. A system according to any of Examples 12-13, wherein the operation further comprises annotating the one or more revision edges, wherein the annotation comprises assigning an API change identifier, an action identifier, and one or more action parameters to at least one revision edge, wherein the API change identifier indicates the API change from the source version to the target version, the action identifier indicates a standard function for the at least one revision edge, and the one or more action parameters specify inputs to the standard function.

[0320] Example 15. The system of any of Examples 12-14, wherein the installing comprises retrieving the one or more standard functions from a code repository.

[0321] Example 16. A system according to any one of Examples 12-15, wherein the operation further comprises: generating, for the selected revision edge, a list of available standard functions suitable for implementing changes to the API represented by the selected revision edge; and selecting a target standard function from the list of available standard functions, wherein the installation comprises downloading the target standard function.

[0322] Example 17. The system of Example 16, wherein the operations further comprise ranking the list of available standard functions based on user download counts of the available standard functions, providers of the available standard functions, or both.

[0323] Example 18. A system according to any of Examples 11-17, wherein the retrieved difference graph is selected from a plurality of difference graphs connected from a source knowledge graph to a target knowledge graph, wherein the plurality of difference graphs include corresponding revision edges, and wherein the plurality of difference graphs are ranked based on a count of users selecting the plurality of difference graphs to update an API, a provider of the plurality of difference graphs, or both.

[0324] Example 19. A system according to any of Examples 11-18, wherein at least one of the function packages is configured to change the data type of a metadata object from the source version of the API to the target version of the API.

[0325] Example 20. One or more non-transitory computer-readable media having computer-executable instructions encoded thereon, the computer-executable instructions causing one or more processors to execute a method comprising: specifying a source version and a target version of an application programming interface (API) and a target programming language; retrieving a difference graph connecting from a source knowledge graph representing the source version of the API to a target knowledge graph representing the target version of the API, wherein the difference graph comprises one or more revision edges representing changes of the API between the source version and the target version; installing one or more function packages written in the target programming language and associated with the one or more revision edges; and running the one or more function packages to update the API from the source version to the target version, wherein at least one of the function packages is configured to change the data type of a metadata object from the source version of the API to the target version of the API.

[0326] Example 33 - Example Alternative

[0327] The techniques from any example can be combined with the techniques described in any one or more other examples. In view of the many possible embodiments to which the principles of the disclosed technology can be applied, it should be recognized that the illustrated embodiments are examples of the disclosed technology and should not be considered as limiting the scope of the disclosed technology. Instead, the scope of the disclosed technology includes that covered by the scope and spirit of the appended claims.

Claims

1. A computer-implemented method comprising: Specify the source and target versions of the application programming interface (API) and the target programming language; retrieving a difference graph connected from a source knowledge graph representing the source version of the API to a target knowledge graph representing the target version of the API, wherein the difference graph includes one or more revision edges representing changes of the API between the source version and the target version; installing one or more function packages written in the target programming language and associated with the one or more revision edges; and The one or more function packages are run to update the API from the source version to the target version.

2. The method according to claim 1, further comprising: The one or more function packages are derived from one or more standard functions linked to the one or more revision edges, wherein the one or more standard functions are written in a language different from the target programming language. 3 . The method of claim 2 , further comprising defining the one or more standard functions for implementing the change to the API represented by the corresponding revision edge.

4. The method according to claim 3, wherein: The one or more standard functions are defined based on a general standard action, wherein the general standard action defines variable input types, variable return types, and parameter constructions of the one or more standard functions, wherein the parameter constructions represent a variable set of parameter names and parameter values ​​that are input parameters of the one or more standard functions.

5. The method according to claim 2 further includes annotating the one or more revision edges, wherein the annotation includes assigning an API change identifier, an action identifier, and one or more action parameters to at least one revision edge, wherein the API change identifier indicates the API change from the source version to the target version, the action identifier indicates a standard function for the at least one revision edge, and the one or more action parameters specify inputs to the standard function.

6. The method according to claim 2, wherein: The installing includes retrieving the one or more standard functions from a code repository.

7. The method according to claim 2, further comprising: For the selected revision edge, generating a list of available standard functions suitable for implementing the change of the API represented by the selected revision edge; and selecting a target criterion function from the list of available criterion functions, The installation includes downloading the target standard function.

8. The method of claim 7, further comprising ranking the list of available standard functions based on user download counts of the available standard functions, providers of the available standard functions, or both.

9. The method according to claim 1, wherein: The retrieved difference graph is selected from a plurality of difference graphs connected from the source knowledge graph to the target knowledge graph, wherein the plurality of difference graphs include corresponding revision edges, wherein the plurality of difference graphs are ranked based on a count of a user selecting the plurality of difference graphs to update an API, a provider of the plurality of difference graphs, or both.

10. The method according to claim 1, wherein: At least one of the function packages is configured to change a data type of a metadata object from the source version of the API to the target version of the API.

11. A computing system comprising: Memory; one or more hardware processors coupled to the memory; and One or more computer-readable storage media storing instructions that, when loaded into the memory, cause the one or more hardware processors to perform operations comprising: Specify the source and target versions of the application programming interface (API) and the target programming language; retrieving a difference graph connected from a source knowledge graph representing the source version of the API to a target knowledge graph representing the target version of the API, wherein the difference graph includes one or more revision edges representing changes of the API between the source version and the target version; installing one or more function packages written in the target programming language and associated with the one or more revision edges; and The one or more function packages are run to update the API from the source version to the target version.

12. The system according to claim 11, wherein: The operations also include deriving the one or more function packages from one or more standard functions linked to the one or more revision edges, wherein the one or more standard functions are written in a language different from the target programming language.

13. The system according to claim 12, wherein: The operations also include defining the one or more standard functions for implementing the change to the API represented by the corresponding revision edge.

14. The system according to claim 12, wherein: The operation also includes annotating the one or more revision edges, wherein the annotation includes assigning an API change identifier, an action identifier, and one or more action parameters to at least one revision edge, wherein the API change identifier indicates the API change from the source version to the target version, the action identifier indicates a standard function for the at least one revision edge, and the one or more action parameters specify inputs to the standard function.

15. The system of claim 12, wherein: The installing includes retrieving the one or more standard functions from a code repository.

16. The system of claim 12, wherein: The operations also include: generating, for the selected revision edge, a list of available standard functions suitable for implementing the change to the API represented by the selected revision edge; and selecting a target criterion function from the list of available criterion functions, The installation includes downloading the target standard function.

17. The system of claim 16, wherein: The operations also include ranking the list of available standard functions based on user download counts of the available standard functions, providers of the available standard functions, or both.

18. The system of claim 11, wherein: The retrieved difference graphs are selected from a plurality of difference graphs connected from a source knowledge graph to a target knowledge graph, wherein the plurality of difference graphs include corresponding revision edges, wherein the plurality of difference graphs are ranked based on a count of a user selecting the plurality of difference graphs to update an API, a provider of the plurality of difference graphs, or both.

19. The system of claim 11, wherein: At least one of the function packages is configured to change a data type of a metadata object from the source version of the API to the target version of the API.

20. One or more non-transitory computer-readable media having computer-executable instructions encoded thereon, the computer-executable instructions causing one or more processors to perform a method comprising: Specify the source and target versions of the application programming interface (API) and the target programming language; retrieving a difference graph connected from a source knowledge graph representing the source version of the API to a target knowledge graph representing the target version of the API, wherein the difference graph includes one or more revision edges representing changes of the API between the source version and the target version; installing one or more function packages written in the target programming language and associated with the one or more revision edges; and running the one or more function packages to update the API from the source version to the target version, Wherein, at least one of the function packages is configured to change the data type of the metadata object from the source version of the API to the target version of the API.

Images