Contextual application programming interface gateway

Abstract

Various examples relate to systems and methods for implementing an application programming interface (API) gateway. The API gateway may receive an API call directed to an exposed API associated with the backend system. The API gateway may execute the trained computerized model based at least in part on the API call and at least in part on API call context data associated with the API call. The API gateway may determine a routing action for the API call based at least in part on an output of the trained computerized model, and perform the routing action for the API call.

Description

Technical Field

[0001] The various examples described herein relate to an Application Programming Interface (API) gateway configured to process API calls to exposed APIs in a dynamic manner based on context data. Background Art

[0002] An Application Programming Interface (API) gateway is a computer-implemented component located between an exposed API and a user or other system that utilizes the exposed API. API calls intended for the exposed API are directed to the API gateway. The API gateway can be configured to apply one or more policies to incoming API calls. If the API call is consistent with the applied policies, the API gateway can route the API call to the exposed API. Summary of the Invention

[0003] In an embodiment, a computing system for implementing an Application Programming Interface (API) gateway includes: at least one hardware processor programmed to perform operations including: receiving, by the API gateway, an API call directed to an exposed API associated with a backend system; executing, by the API gateway, a trained computerized model at least partially based on the API call and at least partially based on API call context data associated with the API call; determining, by the API gateway, a routing action for the API call at least partially based on an output of the trained computerized model; and performing, by the API gateway, the routing action for the API call.

[0004] Details of one or more embodiments of the subject matter of this specification are set forth in the detailed description, claims, and drawings. Other features, aspects, and advantages of the subject matter will become apparent to those of ordinary skill in the art from the detailed description, claims, and drawings. Brief Description of the Drawings

[0005] The present disclosure is illustrated by way of example and not limitation in the following drawings.

[0006] Figure 1 is a diagram illustrating one example of an environment including an Application Programming Interface (API) gateway serving one or more computing systems.

[0007] Figure 2 is a diagram illustrating Figure 1 one example of a processing flow for a routing action that can be performed by an API gateway to select and perform an incoming API call.

[0008] Figure 3 is a diagram illustrating Figure 1 another example of a processing flow for a routing action that can be performed by an API gateway to select and perform an incoming API call.

[0009] Figure 4 is a flowchart showing another example of a processing flow of routing actions that can be performed by an Figure 1 API gateway to select and execute an incoming API call.

[0010] Figure 5 is a flowchart showing another example of a processing flow of routing actions that can be performed by an Figure 1 API gateway to select and execute an incoming API call.

[0011] Figure 6 is a flowchart showing another example of a processing flow of routing actions that can be performed by an Figure 1 API gateway to select and execute an incoming API call.

[0012] Figure 7 is a flowchart showing another example of a processing flow of routing actions that can be performed by an Figure 1 API gateway to select and execute an incoming API call.

[0013] Figure 8 is a processing flow that can be executed to train a trained computerized model to determine routing actions for API calls to an Figure 1 API gateway.

[0014] Figure 9 is a block diagram showing an example of a software architecture for a computing device.

[0015] Figure 10 is a block diagram of a machine in an example form of a computer system, in which instructions can be executed to cause the machine to perform any one or more of the methods discussed herein. DETAILED DESCRIPTION

[0016] The various examples described herein relate to an application programming interface (API) gateway configured to dynamically process API calls to exposed APIs based on context data. For example, many API gateways are arranged to apply policies as predefined rules without considering the context of the API call. For example, an API gateway can apply a predefined throttling rule to an API call. If a particular originating user or system makes more than a threshold number of API calls during a given period, subsequent API calls from that originating user or system can be restricted. In another example, an API gateway can apply a predefined static rule to an API call. API calls from an originating user or system indicated by the static rule can be routed to the exposed API, while other API calls are throttled.

[0017] An API gateway that applies predefined rules without considering context data may be suitable for some applications. For example, a backend server or other system that utilizes the exposed API can process API calls based on the static predefined rules of the API gateway and / or can apply additional logic at the backend. However, in some examples, this may consume resources at the backend system and / or completely limit the flexibility of the backend system.

[0018] Various examples utilize a context API gateway to address these and other challenges. The API gateway can be configured to execute a trained computerized model. The API gateway can receive an API call directed to the exposed API. In response, the API gateway can execute the trained computerized model. The input to the trained computerized model can include context data associated with the API request. The context data can describe, for example, data about the originating user of the API call, network load data describing the load of at least one network between the API gateway and the exposed API, communication session data describing the type of communication distribution associated with the API call, network data describing the network from which the API call originated, geographic data describing the geographic location from which the API call originated, version data describing the version of the sending application associated with the API call, time data describing the time and date when the API call was made, and / or the like.

[0019] The output of the trained computerized model can be used by the API gateway to determine the routing action for the API call. For example, the API call can be routed to a server associated with the exposed API or can be rejected. In some examples, the routing action can include generating content data that describes the content to be provided in response to the API call and sending the API call and the content data to the exposed API. In some examples, the routing action can include performing a specific authentication process before routing the API call to the exposed API. Various other routing actions can be indicated by the output of the trained computerized model.

[0020] Figure 1 FIG. is an example of an environment 100 showing an API gateway 102 serving one or more computing systems 104, 106. The API gateway 102 can receive API calls from various API call initiators. For example, some API calls can originate from originating users 128, 130 via user computing devices 132, 134. The user computing devices 132, 134 can be and / or include various different types of computing devices, such as, for example, desktop computers, laptop computers, tablet computers, mobile computing devices, and / or the like. Additionally, in some examples, one or more API calls can be received from originating applications executing at one or more originating computing systems 136, 138.

[0021] API calls received by the API gateway 102 can be directed to one or more exposed APIs 108, 110, 112, 114, 116, 118. The exposed APIs 108, 110, 112, 114, 116, 118 can be associated with one or more backend systems 120, 122 at one or more computing systems 104, 106. The API gateway 102 can receive the corresponding API calls, determine a routing action for each corresponding API call, and perform the routing action.

[0022] The computing systems 104, 106 can include corresponding backend systems 120, 122 that implement various software applications and / or services involving interactions with one or more users 128, 130 and / or originating computing systems 136, 138.

[0023] The computing systems 104, 106 can expose corresponding exposed APIs 108, 110, 112, 114, 116, 118 to facilitate interactions between one or more software applications executed at the corresponding backend systems 120, 122 and the originating users 128, 130 and / or originating computing systems 136, 138. In some examples, the backend systems 120, 122 can expose different APIs 108, 110, 112, 114, 116, 118. For example, different APIs 108, 110, 112, 114, 116, 118 can be exposed to provide different functions to the users 128, 130 and / or originating computing systems 136, 138. Additionally, in some examples, the different exposed APIs 108, 110, 112, 114, 116, 118 can correspond to different service levels, different networks, different geographical regions, and / or the like. In some examples, the different exposed APIs 108, 110, 112, 114, 116, 118 can correspond to different versions of the originating software applications executed, for example, in the user computing devices 132, 134 or the originating computing systems 136, 138.

[0024] API calls directed to one or more of the exposed APIs 108, 110, 112, 114, 116, 118 can first be directed to the API gateway 102. The API gateway 102 can determine the routing action for each API call based on context data, as described herein, for example. In this way, the computing systems 104, 106 and the exposed APIs 108, 110, 112, 114, 116, 118 can consume the API gateway services provided by the API gateway 102.

[0025] Consider an example where the backend system 120 executes an electronic or e-commerce application. Users 128, 130 can access the e-commerce application to purchase products and / or services. In some examples, the backend system 120 can expose an exposed API 108 to implement a shopping cart function. For example, calls can be made to the exposed API 108 to add items to a user's shopping cart, subtract items from a user's shopping cart, fulfill an order for one or more items in a user's shopping cart, and / or the like. The backend system 120 can expose an exposed API 110 to provide a catalog function. Then, API calls to the exposed API 110 can request to display one or more goods or services for sale via the e-commerce application. In some examples, different exposed APIs can be customized for different devices. For example, the exposed API 110 can be configured to respond to catalog function requests from a mobile device, while the exposed API 112 can be configured to respond to catalog function requests from a desktop device.

[0026] Consider another example where the backend system 122 provides a social media application. The social media application can expose an exposed API 114 to receive API calls from origin users 128, 130 requesting a personalized feed. The social media application can also expose an exposed API 118 to receive search queries from one or more origin users 128, 130. As described, different exposed APIs 114, 116, 118 can be arranged to provide different services to origin users 128, 130 and origin computing systems 136, 138 to serve different geographic regions, serve different versions of the origin application, and / or the like.

[0027] The API gateway 102 and the computing systems 104, 106 can be executed at any suitable computing system. In some examples, the API gateway 102 is executed in an on-premises environment. The on-premises environment includes one or more computing systems maintained by the provider of the API gateway 102. For example, the provider can generate code for executing the API gateway 102 and execute the code in the on-premises environment. Users 128, 130 can remotely access the on-premises computing systems via user computing devices 132, 134.

[0028] In some examples, the API gateway 102 is executed in a private cloud environment. In a private cloud environment, a cloud service provider grants access to computing hardware such as servers, data storage, and / or the like. The customer enterprise provides the software in the data executed and stored in the private cloud environment. For example, in a private cloud implementation, the developer of the API gateway 102 can provide executable code for implementing the API gateway 102 to the private cloud environment.

[0029] In some examples, the API gateway 102 may be executed in a public cloud environment. The public cloud environment includes one or more servers or other computing hardware. The public cloud environment may be arranged as multiple tenancies implemented by a cloud service provider. Each tenancy may be associated with a customer enterprise and accessible by users associated with that customer enterprise. The cloud service provider may provide one or more executable files, underlying data, and / or other components to implement the API gateway 102.

[0030] The computing systems 104, 106 may similarly be executed at any suitable computing system including an on-premises environment, a private cloud environment, and / or a public cloud environment. In some examples, the API gateway 102 is executed under a tenancy of a public cloud environment, while all or part of the computing systems 104, 106 are executed under other tenancies of the same or a different public cloud environment.

[0031] The API gateway 102 may include a trained computerized model 124, a trainer subsystem 125, and / or a rule engine 126. The trained computerized model 124 may be or include any kind of trained computerized model architecture. In some examples, the trained computerized model 124 may be or include a logistic regression model, a decision tree model, a random forest model, a support vector machine model, a K-nearest neighbor model, a gradient boosting model, an Adaptive Boosting (AdaBoost) model, a neural network model, an Extreme Gradient Boosting (XGBoost) model, and / or the like.

[0032] The trained computerized model 124 may be trained to receive an API call (and / or its description) and API call context data as input. The output of the trained computerized model 124 may indicate a routing action for the input API call. The routing action may include routing the API call to a particular exposed API 108, 110, 112, 114, 116, 118. The routing action may also include various other operations. For example, the routing action may include determining the content that should be provided in response to the API call. Thus, the API gateway 102 may generate content data describing the content that should be provided in response to the API call. The API gateway 102 may forward the API call and the content data to the exposed API 108, 110, 112, 114, 116, 118 that the API call is directed to. In some examples, the routing action may involve throttling or rejecting the API call. This may be done, for example, by failing to forward the API call to any of the exposed APIs 108, 110, 112, 114, 116, 118.

[0033] In some examples, the routing action can include performing an authentication process before routing the API call to the appropriate exposed APIs 108, 110, 112, 114, 116, 118. The type of authentication process to be performed can be based on the output of the trained computerized model 124. For example, the output of the trained computerized model can indicate that some API calls should undergo multi-factor authentication, while other API calls can undergo single-factor authentication.

[0034] In some examples, the routing action can include directing the API call to a specific exposed API 108, 110, 112, 114, 116, 118. For example, the routing action can be based on the version of the software application making the API call. The output of the trained computerized model 124 can indicate the specific exposed API 108, 110, 112, 114, 116, 118 that is most suitable for handling calls from that software application or its version. Additionally, in some examples, if the context data indicates an error or other failure at the primary server or the exposed API 108, 110, 112, 114, 116, 118, the routing action can include routing the API call to a backup server or a backup exposed API 108, 110, 112, 114, 116, 118.

[0035] In some examples, the API gateway 102 can implement a trainer subsystem 125. For example, as described herein, the trainer subsystem 125 can be executed to train the trained computerized model 124 using training data. In some examples, the API gateway 102 also includes a rule engine 126. The rule engine 126 can apply one or more rules to the API call. In some examples, the routing action for a particular API call can be based on the application of the rule engine 126 and the output of the trained computerized model 124. In some examples, the rule engine 126 is programmed to implement the rules generated by the trained computerized model 124.

[0036] Figure 2 is an example of a process flow 200 that can be performed by an API gateway (such as Figure 1 the API gateway 102) to select and execute a routing action for an incoming API call. At operation 202, the API gateway 102 can receive an API call from an API call initiator. The API call initiator can be, for example, an originating user 128, 130 (via the user computing devices 132, 134 and the originating application executing thereon) or an originating computing system 136, 138 (via the originating application executing thereon).

[0037] At operation 204, the API gateway 102 executes the trained computerized model 124. The trained computerized model 124 is executed based on API call context data. The API call context data describes the context of the API call. Various different types of API call context data can be used. In some examples, when the API call initiator is the originating user 128, 130, the API call context data can include originating user data that describes the originating users 128, 130. The originating user data can include, for example, user history data that describes past API calls made by the originating user and / or other users associated with a common account or common enterprise. The originating user data can also include user preference data that describes at least one preference of the originating users 128, 130. Additionally, in some examples, the originating user data can include count data that describes the account associated with the originating users 128, 130.

[0038] In some examples, the context data can also include network load data. The network load can describe the load on one or more networks located between the API gateway 102 and the computing systems 104, 106 to which the API call is directed. For example, there can be multiple networks or network boards between the API gateway 102 and the computing systems 104, 106 to which the API call is directed. The network load data can indicate to the API gateway 102 the networks or network paths to utilize and / or avoid.

[0039] In some examples, the context data can also include communication session data that describes the type of communication session associated with the API call. For example, the communication session data can indicate that the API call is associated with a live event such as a streaming video, audio, or similar session. Such communication session data can indicate to the API gateway 102 that the API request should be prioritized over other API requests that are not part of the live event.

[0040] In some examples, the context data can include geographic data that describes the geographic location of the API call initiator. In some examples, the context data can include network data that describes the network from which the API call initiator originated or the network through which the API call passed before reaching the API gateway 102. In some examples, this can indicate the level of authentication or other security to apply to the API call. In some examples, the context data can include version data that describes the version of the sending application that initiated the API call. Additionally, in some examples, the context data can include time data that describes the time of day, day of the week, or other indicator of when the API call was sent.

[0041] At operation 204, the API gateway 102 executes the trained computerized model 124 using the context data as input. The output of the trained computerized model 124 may indicate a routing action for the API call. At operation 206, the API gateway 102 may determine a routing action for the API call based on the output of the trained computerized model 124. At operation 208, the API gateway 102 may execute the determined routing action.

[0042] Figure 3 is a flowchart showing an example of a process flow 300 that may be performed by an API gateway (such as Figure 1 API gateway 102) to select and execute a routing action for an incoming API call. Process flow 300 shows an arrangement that utilizes a trained computerized model 124 and a rule engine 126. At operation 302, the API gateway 102 may receive an API call from an API call initiator. The API call initiator may be, for example, an originating user 128, 130 (via a user computing device 132, 134 and an originating application executing thereon) or an originating computing system 136, 138 (via an originating application executing thereon).

[0043] At operation 304, the API gateway 102 executes the trained computerized model 124. In some examples, for instance, as described herein, the trained computerized model 124 is executed based on context data that describes the API call. In some examples, the output of the trained computerized model may also indicate one or more rules to be applied to the API call by the rule engine 126.

[0044] At operation 306, the API gateway 102 may execute the rule engine 126 using the context data as input. The rule engine 126 may apply one or more context rules to the API call. In some examples, one or more rules implemented by the rule engine 126 may be determined based on the output of the trained computerized model executed at operation 304.

[0045] At operation 308, the API gateway 102 may determine a routing action for the API call. In some examples, the routing action for the API call may be based on the output of the rule engine 126, the output of the trained computerized model 124, and / or both. At operation 310, the API gateway 102 may execute the determined routing action.

[0046] Figures 4 - 8 is a process flow showing an example of how the API gateway 102 may respond to various API calls. Each Figures 4 - 8 describes a routing action for an API call that includes different operations. It should be understood that in some examples, the API gateway 102 may determine an inclusionFigures 4 - 8 routing actions that are any suitable combination of the routing actions described in

[0047] Figure 4 is a flowchart showing an example of a process flow 400 of routing actions that can be performed by an API gateway (such as Figure 1 API gateway 102) of Figure 4 to select and execute an incoming API call. In the example of

[0048] At operation 402, API gateway 102 may receive an API call from an API call initiator. The API call initiator may be, for example, an originating user 128, 130 (via user computing devices 132, 134 and an originating application executing thereon) or an originating computing system 136, 138 (via an originating application executing thereon). At operation 404, API gateway 102 executes a trained computerized model 124. In some examples, for instance, as described herein, the trained computerized model 124 is executed based on context data describing the API call.

[0049] At operation 406, API gateway 102 determines a routing action for the API call, which includes forwarding the API call along with content data to exposed APIs 108, 110, 112, 114, 116, 118. In some examples, the identity of the exposed APIs 108, 110, 112, 114, 116, 118 to which the API call will be forwarded and the determination that the API call will be forwarded along with content data may be based on the output of the trained computerized model.

[0050] At operation 408, API gateway 102 may generate content data. The content data may describe the content that should be returned to the initiator of the API call in response to the API call. Consider the example where the API call initiator is an originating user 128, 130 and the API call is to a social media or other content service. For example, the content data may be determined based on context data indicating the preferences of the originating users 128, 130, the past behavior of the originating users 128, 130, and / or the like. In some examples, the content data may be generated based on the output of the trained computerized model 124. At operation 410, API gateway 102 routes the API call along with the content data to the appropriate exposed APIs 108, 110, 112, 114, 116, 118.

[0051] Figure 5 is a flowchart showing an example of a process flow 400 of routing actions that can be performed by an API gateway (such as Figure 1A flowchart of an example of a processing flow 500 performed by an API gateway 102 to select and perform a routing action for an incoming API call. In Figure 5 the example, the routing action includes prompting and / or performing an authorization process for the API call. This can ensure that the API call is legal.

[0052] At operation 502, the API gateway 102 can receive an API call from an API call initiator. The API call initiator can be, for example, an originating user 128, 130 (via a user computing device 132, 134 and an originating application executing thereon) or an originating computing system 136, 138 (via an originating application executing thereon). At operation 504, the API gateway 102 executes a trained computerized model 124. In some examples, for instance, as described herein, the trained computerized model 124 is executed based on context data describing the API call.

[0053] At operation 506, the API gateway 102 determines to forward the API call to an exposed API 108, 110, 112, 114, 116, 118 if authorized. For example, the output of the trained computerized model 124 can indicate that the API call should undergo an authorization process and / or the specific authorization process that the API call should undergo. The output of the trained computerized model 124 can also indicate the exposed API 108, 110, 112, 114, 116, 118 to which the API call should be routed.

[0054] At operation 508, the API gateway 102 can perform the indicated authorization process. The indicated authentication process can be any suitable type of authentication process, such as, for example, a multi-factor authentication process, a single-factor authentication process, and / or the like. Examples of a single authentication process include a password, a personal identification number (PIN), and / or the like. The API gateway 102 can perform the authorization process and / or can send a message to the initiator of the API call requesting the initiator to perform an authentication process at a third-party provider, such as, for example, an authorization certificate or other suitable authentication provider. At operation 510, the API gateway 102 determines whether the initiator of the API call has passed the authentication process. If the initiator of the API call has passed the authentication process, then at operation 514, the API gateway 102 can pass the API call to an appropriate exposed API 10A, 110, 112, 114, 116, 118. If the initiator of the API call has not passed the authentication process, then the API gateway 102 can discard the API call at operation 512.

[0055] Figure 6 is a diagram showing that it can be performed by an API gateway such as Figure 1Flowchart of an example of process flow 600 that an API gateway (such as API gateway 102) performs to select and execute a routing action for an incoming API call. In Figure 6 the example, the routing action includes selecting a specific version of the exposed APIs 108, 110, 112, 114, 116, 118.

[0056] At operation 602, API gateway 102 may receive an API call from an API call initiator. The API call initiator may be, for example, an originating user 128, 130 (via user computing devices 132, 134 and an originating application executing thereon) or an originating computing system 136, 138 (via an originating application executing thereon). At operation 604, API gateway 102 executes a trained computerized model 124. In some examples, for instance, as described herein, the trained computerized model 124 is executed based on context data describing the API call.

[0057] At operation 606, API gateway 102 determines a selected version of the exposed APIs 108, 110, 112, 114, 116, 118 to which the API call is to be forwarded. The selected version may be indicated by the output of the trained computerized model. In some examples, the output of the trained computerized model 124 may indicate the version of the exposed API to which the API call should be directed. This may be determined based on context data provided as input to the trained computerized model, such as, for example, the version of the application executing on the user computing devices 132, 134 or the originating computing systems 136, 138 that initiated the API call. At operation 608, API gateway 102 may route the API call to the indicated version of the exposed API.

[0058] Figure 7 is a flowchart of an example of process flow 700 that can be performed by an API gateway (such as Figure 1 API gateway 102) to select and execute a routing action for an incoming API call. In Figure 7 the example, the routing action includes detecting an error in the exposed APIs 108, 110, 112, 114, 116, 118 and routing the API call to a backup server for the exposed APIs 108, 110, 112, 114, 116, 118.

[0059] At operation 702, the API gateway 102 can receive an API call from an API call initiator. The API call initiator can be, for example, an originating user 128, 130 (via a user computing device 132, 134 and an originating application executing thereon) or an originating computing system 136, 138 (via an originating application executing thereon). At operation 704, the API gateway 102 executes the trained computerized model 124. In some examples, for instance, as described herein, the trained computerized model 124 is executed based on context data describing the API call.

[0060] At operation 706, the API gateway 102 determines to forward the API call to an exposed API having an associated error backup server. At operation 708, the API gateway 102 can detect an error at the exposed API. In some examples, the error is detected based on the output of the trained computerized model 124. For example, the trained computerized model 124 can predict an error at the exposed API based on the context data. At operation 708, the API gateway 102 detects an error at the exposed API to which the API call is to be forwarded. In some examples, the output of the trained computerized model 124 indicates an error. The API gateway 102 can determine an error response. The error response can include, for example, rejecting the API call or causing the API call to fail and / or forwarding the API call to a backup server associated with the same backend systems 120, 122 as the error-exposed API. At operation 710, the API gateway 102 can execute the error response.

[0061] Figure 8 is a process flow 800 that can be executed to train the trained computerized model 124. In some examples, the processing flow 800 is executed by a trainer subsystem 125 of the API gateway 102. In other examples, the processing flow 800 is executed by another computing system. Thus, in some examples, the trained computerized model 124 can be loaded into the API gateway 102 after the API gateway 102 has been trained.

[0062] At operation 802, the trainer subsystem 125 generates training data for training the trained computerized model 124. The training data describes actual or hypothetical API calls and associated context data. The training data can also include a label for each respective API call. The label indicates the desired routing action for the API call. For example, the label can indicate the exposed APIs 108, 110, 112, 114, 116, 118 to which the API call should be routed. The label can also describe other operations as part of the desired routing action, such as generating content data for the API call, the authorization process for the API call, the version of the exposed API that the API call should point to, an indication of an error at the exposed API and / or an associated backup server. The label for the training data can be determined based on log data describing the disposition of previous API calls and / or can be generated and / or modified by a human user.

[0063] At operation 804, the trainer subsystem 125 can execute the trained computerized model 124 using a portion of the training data as input. This can result in an output of the trained computerized model 124. At operation 806, the trainer subsystem 125 can modify the trained computerized model based on the output generated at operation 804 and the label associated with the training data. For example, the trainer subsystem 125 can compare the output of the trained computerized model 124 with the label data and determine corresponding changes to the trained computerized model to minimize the difference between the output of the trained computerized model 124 and the training data. Any suitable technique can be used to determine the error between the model output and the label data and to generate the changes. In some examples, the trainer subsystem 125 is configured to apply a gradient descent technique to a loss function that describes the difference between the result of the trained computerized model 124 and the label of the corresponding training data.

[0064] At operation 810, the trainer subsystem 125 can determine whether it has executed the last epoch of training. If not, the trainer subsystem 125 can return to operation 804 and execute the model again with additional training data. If the current epoch is the last training epoch, training can be completed at operation 812.

[0065] In view of the foregoing disclosure, various examples are set forth below. It should be noted that one or more features of the examples, taken alone or in combination, should be considered within the disclosure of this application.

[0066] Example:

[0067] Example 1 is a computing system for implementing an Application Programming Interface (API) gateway. The computing system includes: at least one hardware processor programmed to perform operations that include: receiving, by the API gateway, an API call directed to an exposed API associated with a backend system; performing, by the API gateway, a trained computerized model at least partially based on the API call and at least partially based on API call context data associated with the API call; determining, by the API gateway, a routing action for the API call at least partially based on an output of the trained computerized model; and performing, by the API gateway, the routing action for the API call.

[0068] In Example 2, the subject matter of Example 1 optionally includes that the routing action for the API call includes routing the API call to a first server associated with the exposed API.

[0069] In Example 3, the subject matter of any one or more of Examples 1-2 optionally includes: the routing action for the API call includes rejecting the API call.

[0070] In Example 4, the subject matter of any one or more of Examples 1-3 optionally includes: the routing action for the API call includes routing the API call to an exposed API having first content data that describes first content to be returned in response to the API call.

[0071] In Example 5, the subject matter of any one or more of Examples 1-4 optionally includes that the output of the trained computerized model indicates a first authentication process, and the routing action for the API call includes: determining that the API call passes the authentication process; and after determining that the API call passes the authentication process, routing the API call to the exposed API.

[0072] In Example 6, the subject matter of any one or more of Examples 1-5 optionally includes: the routing action for the API call includes routing the API call to a version of the exposed API indicated by the output of the trained computerized model.

[0073] In Example 7, the subject matter of any one or more of Examples 1-6 optionally includes that the output of the trained computerized model indicates an error response associated with the API call, and the operations further include: detecting, by the API gateway, an error associated with the exposed API; and performing the error response, where performing the error response includes at least one of rejecting the API call or routing the API call to a backup server associated with the exposed API.

[0074] In Example 8, the subject matter of any one or more of Examples 1-7 optionally includes that the API call context data includes origin user data describing the origin user associated with the API call, and the origin user data includes at least one of user history data describing past API calls made by the origin user, user preference data describing at least one preference of the origin user, or user account data describing the account of the origin user.

[0075] In Example 9, the subject matter of any one or more of Examples 1-8 optionally includes: the API call context data includes network load data describing the load of at least one network between the API gateway and the exposed API.

[0076] In Example 10, the subject matter of any one or more of Examples 1-9 optionally includes: the API call context data includes communication session data describing the type of communication session associated with the API call.

[0077] In Example 11, the subject matter of any one or more of Examples 1-10 optionally includes: the API call context data includes geographical data describing the geographical location from which the API call originated.

[0078] In Example 12, the subject matter of any one or more of Examples 1-11 optionally includes: the API call context data includes network data describing the network from which the API call originated.

[0079] In Example 13, the subject matter of any one or more of Examples 1-12 optionally includes: the API call context data includes version data describing the version of the sending application associated with the API call.

[0080] In Example 14, the subject matter of any one or more of Examples 1-13 optionally includes: the API call context data includes time data describing the time of day when the API call is made.

[0081] Example 15 is a method of operating an application programming interface (API) gateway, the method including: receiving, by the API gateway, an API call directed to an exposed API associated with a backend system; executing, by the API gateway, a computerized model trained at least in part based on the API call and at least in part based on API call context data associated with the API call; determining, by the API gateway, a routing action for the API call at least in part based on the output of the trained computerized model; and executing, by the API gateway, the routing action for the API call.

[0082] In Example 16, the subject matter of Example 15 optionally includes: the routing action for the API call includes routing the API call to a first server associated with the exposed API.

[0083] In Example 17, the subject matter of any one or more of Examples 15 - 16 optionally includes: a routing action for an API call includes rejecting the API call.

[0084] In Example 18, the subject matter of any one or more of Examples 15 - 17 optionally includes: a routing action for an API call includes routing the API call to an exposed API having first content data that describes first content to be returned in response to the API call.

[0085] In Example 19, the subject matter of any one or more of Examples 15 - 18 optionally includes an output of a trained computerized model indicating a first authentication process, and a routing action for an API call includes: determining that the API call passes the authentication process; and after determining that the API call passes the authentication process, routing the API call to an exposed API.

[0086] Example 20 is a non - transitory machine - readable medium having instructions thereon that, when executed by at least one hardware processor, cause the at least one hardware processor to perform operations that include: receiving an API call directed to an exposed API associated with a backend system; performing a trained computerized model at least in part based on the API call and at least in part based on API call context data associated with the API call; determining a routing action for the API call at least in part based on an output of the trained computerized model; and performing the routing action for the API call.

[0087] Figure 9 FIG. 900 is a block diagram illustrating an example of a software architecture 902 for a computing device. The architecture 902 can be used in conjunction with various hardware architectures, for example, as described herein. Figure 9 This is merely a non - limiting example of a software architecture, and many other architectures can be implemented to facilitate the functions described herein. Figure 9 The software architecture 902 and various other components described herein can be used to implement various other systems described herein. For example, the software architecture 902 illustrates an example way to implement an API gateway 102, computing systems 104, 106, or other computing devices described herein.

[0088] In Figure 9 , a representative hardware layer 904 is shown, and it can represent, for example, any of the computing devices described above. In some examples, the hardware layer 904 can be implemented according to Figure 9 the architecture of a computer system.

[0089] The representative hardware layer 904 includes one or more processing units 906 with associated executable instructions 908. The executable instructions 908 represent the executable instructions of the software architecture 902, including implementations in the methods, modules, subsystems, components, etc. described herein, and may also include a memory and / or storage module 910 that also has the executable instructions 908. The hardware layer 904 may also include other hardware indicated by other hardware 912, where other hardware 912 represents any other hardware of the hardware layer 904, such as other hardware illustrated as part of the architecture 902.

[0090] In Figure 9 the example architecture, the software architecture 902 can be conceptualized as a stack of layers, where each layer provides a specific function. For example, the software architecture 902 may include layers such as an operating system 914, libraries 916, a middleware layer 918 (sometimes referred to as a framework), applications 920, and a presentation layer 944. In operation, an application 920 and / or other components within a layer can make API calls 924 through the software stack and, in response to the API calls 924, access responses, return values, etc. shown as messages 926. The illustrated layers are representative in nature, and not all software architectures have all layers. For example, some mobile or specialized operating systems may not provide a middleware layer 918, while other operating systems may provide such a layer. Other software architectures may include additional or different layers.

[0091] The operating system 914 can manage hardware resources and provide common services. The operating system 914 may include, for example, a kernel 928, services 930, and drivers 932. The kernel 928 can act as an abstraction layer between the hardware and other software layers. For example, the kernel 928 may be responsible for memory management, processor management (e.g., scheduling), component management, networking, security settings, etc. The services 930 can provide other common services for other software layers. In some examples, the services 930 include interrupt services. The interrupt services can detect the receipt of an interruption and, in response, cause the architecture 902 to pause its current processing and execute an interrupt service routine (ISR) when accessing the interruption.

[0092] The drivers 932 can be responsible for controlling or interfacing with the underlying hardware. For example, depending on the hardware configuration, the drivers 932 may include a display driver, a camera driver, a Bluetooth® driver, a flash drive, a serial communication driver (e.g., a Universal Serial Bus (USB) driver), a Wi-Fi® driver, an NFC driver, an audio driver, a power management driver, etc.

[0093] The library 916 can provide a common infrastructure that can be utilized by the application 920 and / or other components and / or layers. The library 916 generally provides functions that allow other software modules to perform tasks in a way that is easier than directly interfacing with the underlying operating system 914 functions (e.g., the kernel 928, services 930, and / or drivers 932). The library 916 can include system 934 libraries (e.g., the C standard library), which can provide functions such as memory allocation functions, string manipulation functions, mathematical functions, and / or the like. Additionally, the library 916 can include API libraries 936, such as media libraries (e.g., libraries for supporting the rendering and manipulation of various media formats such as MPEG4, H.264, MP3, AAC, AMR, JPG, PNG), graphics libraries (e.g., the OpenGL framework that can be used to render 2D and 3D in graphical content on a display), database libraries (e.g., SQLite that can provide various relational database functions), web libraries (e.g., WebKit that can provide web browsing functions), and / or the like. The library 916 can also include a variety of other libraries 938 to provide many other APIs to the application 920 and other software components / modules.

[0094] The middleware layer 918 (sometimes also referred to as middleware) can provide a higher-level common infrastructure that can be utilized by the application 920 and / or other software components / modules. For example, the middleware layer 918 can provide various graphical user interface (GUI) functions, advanced resource management, advanced location services, etc. The middleware layer 918 can provide a broad spectrum of other APIs that can be utilized by the application 920 and / or other software components / modules, some of which can be specific to a particular operating system or platform.

[0095] The application 920 includes built-in applications 940 and / or third-party applications 942. Examples of representative built-in applications 940 can include, but are not limited to, a contacts application, a browser application, a book reader application, a location application, a media application, a messaging application, and / or a game application. Third-party applications 942 can include any of the built-in applications 940 as well as a variety of other applications. In a particular example, third-party applications 942 (e.g., applications developed using the Android™ or iOS™ software development kit (SDK) by entities other than the vendor of a particular platform) can be mobile software running on a mobile operating system such as iOS™, Android™, Windows® Phone, or other mobile computing device operating systems. In this example, the third-party applications 942 can call API calls 924 provided by a mobile operating system such as the operating system 914 to facilitate the functions described herein.

[0096] Application 920 can utilize built-in operating system functions (e.g., kernel 928, services 930, and / or drivers 932), libraries (e.g., system 934, API libraries 936, and other libraries 938), and middleware layer 918 to create a user interface for interacting with the users of the system. Alternatively or additionally, in some systems, the interaction with the user can occur through a presentation layer (such as presentation layer 944). In these systems, the application / module "logic" can be separated from aspects of the application / module that interact with the user.

[0097] Some software architectures utilize virtual machines. For example, the various environments described herein can implement one or more virtual machines that execute to provide a software application or service. Figure 9 An example is shown by virtual machine 948. The virtual machine creates a software environment in which applications / modules can execute as if they were executing on a hardware computing device. Virtual machine 948 is hosted by a host operating system (operating system 914) and typically but not always has a virtual machine monitor 946 that manages the operation of virtual machine 948 and the interface with the host operating system (i.e., operating system 914). Software architectures execute within virtual machine 948, such as operating system 950, libraries 952, framework / middleware 954, applications 956, and / or presentation layer 958. These software architecture layers executed within virtual machine 948 can be the same as or different from the corresponding layers described previously.

[0098] Certain embodiments are described herein as including logic or multiple components, modules, or mechanisms. A module can constitute a software module (e.g., (1) code embodied on a non-transitory machine-readable medium or (2) code embodied in a transmission signal) or a hardware-implemented module. A hardware-implemented module is a tangible unit capable of performing certain operations and can be configured or arranged in a certain manner. In an example embodiment, one or more computer systems (e.g., stand-alone, client, or server computer systems) or one or more hardware processors can be configured by software (e.g., an application or a portion of an application) to operate as a hardware-implemented module that performs certain operations as described herein.

[0099] The various operations of the example methods described herein can be performed, at least in part, by one or more processors temporarily configured (e.g., by software) or permanently configured to perform the relevant operations. Whether temporarily or permanently configured, such processors can constitute processor-implemented modules that operate to perform one or more operations or functions. In some example embodiments, the modules referred to herein can include processor-implemented modules.

[0100] Similarly, the methods described herein can be implemented, at least in part, by a processor. For example, at least some operations of the methods can be performed by one or more processors or modules implemented by a processor. Execution of certain operations can be distributed among one or more processors, not only residing within a single machine but also deployed across multiple machines. In some example embodiments, one or more processors can be located in a single location (e.g., within a home environment, an office environment, or a server farm), while in other embodiments, the processors can be distributed across multiple locations.

[0101] Example embodiments can be implemented in digital electronic circuitry, or in computer hardware, firmware, or software, or in combinations thereof. Example embodiments can be implemented using a computer program product, e.g., a computer program tangibly embodied in an information carrier, e.g., in a machine-readable medium, for execution by, or to control the operation of, a data processing apparatus, e.g., a programmable processor, a computer, or multiple computers.

[0102] Computer software, which includes code for implementing software services, can be written in any form of programming language, including compiled or interpreted languages, and it can be deployed in any form, including as a stand-alone program or as a module, subroutine, or other unit suitable for use in a computing environment. Computer software can be deployed to execute on one computer or at one site or distributed across multiple sites and executed on multiple computers interconnected by a communication network.

[0103] In an example embodiment, operations can be performed by one or more programmable processors executing a computer program to perform a function by operating on input data and generating output.

[0104] Figure 10 FIG. 13 is a block diagram of an example form of a machine, a computer system 1000, in which instructions 1024 can be executed to cause the machine to perform any one or more of the methods discussed herein. In alternative embodiments, the machine operates as a stand-alone device or can be connected (e.g., networked) to other machines. In a networked deployment, the machine can operate in the capacity of a server or a client machine in a server-client network environment, or as a peer machine in a peer-to-peer (or distributed) network environment. The machine can be a personal computer (PC), a tablet PC, a set-top box (STB), a personal digital assistant (PDA), a cellular telephone, a network appliance, a network router, switch or bridge, or any machine capable of executing instructions (sequential or otherwise) specifying actions to be taken by that machine. Further, while only a single machine is shown, the term "machine" shall also be taken to include any collection of machines that individually or jointly execute a set (or multiple sets) of instructions to perform any one or more of the methods discussed herein.

[0105] Example computer system 1000 includes a processor 1002 (e.g., a central processing unit (CPU), a graphics processing unit (GPU), or both), a main memory 1004, and a static memory 1006, which communicate with each other via a bus 1008. The computer system 1000 may also include a video display unit 1010 (e.g., a liquid crystal display (LCD) or a cathode ray tube (CRT)). The computer system 1000 also includes an alphanumeric input device 1012 (e.g., a keyboard or a touch-sensitive display screen), a user interface (UI) navigation (or cursor control) device 1014 (e.g., a mouse), a disk drive unit 1016, a signal generation device 1018 (e.g., a speaker), and a network interface device 1020.

[0106] The disk drive unit 1016 includes a machine-readable medium 1022 on which one or more sets of data structures and instructions 1024 (e.g., software) are stored, which embody any one or more of the methods or functions described herein or are used by any one or more of the methods or functions described herein. The instructions 1024 may also reside, completely or at least partially, within the main memory 1004 and / or within the processor 1002 during execution by the computer system 1000, where the main memory 1004 and the processor 1002 also constitute a machine-readable medium 1022.

[0107] Although the machine-readable medium 1022 is shown as a single medium in the example embodiment, the term "machine-readable medium" may include a single medium or multiple media (e.g., a centralized or distributed database and / or associated caches and servers) that store one or more instructions 1024 or data structures. The term "machine-readable medium" should also be regarded as including any tangible medium that is capable of storing, encoding, or carrying instructions 1024 for execution by a machine and that causes the machine to perform any one or more of the methods of the present disclosure or is capable of storing, encoding, or carrying data structures used by or associated with these instructions 1024. Thus, the term "machine-readable medium" should be regarded as including, but not limited to, solid-state memories as well as optical and magnetic media. Specific examples of the machine-readable medium 1022 include non-volatile memories, such as semiconductor memory devices, e.g., erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), and flash memory devices; magnetic disks, such as internal hard disks and removable disks; magneto-optical disks; and CD-ROM and DVD-ROM disks.

[0108] Instruction 1024 may also be sent or received over a communication network 1026 using a transmission medium. Instruction 1024 may be sent using network interface device 1020 and any one of a number of well-known transfer protocols (e.g., HTTP). Examples of communication networks include local area networks (LANs), wide area networks (WANs), the Internet, mobile telephone networks, plain old telephone (POTS) networks, and wireless data networks (e.g., WiFi and WiMax networks). The term "transmission medium" shall be taken to include any non-transitory medium that is capable of storing, encoding, or carrying instruction 1024 executed by a machine, and includes digital or analog communication signals or other non-transitory media to facilitate the communication of such software.

[0109] Although embodiments have been described with reference to specific example embodiments, it will be apparent that various modifications and changes can be made to these embodiments without departing from the broader spirit and scope of the disclosure. The specification and drawings are, accordingly, to be regarded in an illustrative rather than a restrictive sense. The figures forming a part thereof illustrate, by way of example and not of limitation, specific embodiments in which the subject matter may be practiced. The illustrated embodiments have been described in sufficient detail to enable those skilled in the art to practice the teachings disclosed herein. Other embodiments may be utilized and other embodiments may be derived therefrom, such that structural and logical substitutions and changes may be made without departing from the scope of the disclosure. The detailed description, accordingly, is not to be regarded as limiting in nature, and the scope of various embodiments is defined only by the appended claims and the full scope of equivalents given by those claims.

[0110] Although specific embodiments have been shown and described herein, it should be understood that any arrangement calculated to achieve the same purpose may be substituted for the specific embodiments shown. The disclosure is intended to cover any and all adaptations or variations of various embodiments. Combinations of the above embodiments, as well as other embodiments not specifically described herein, will be apparent to those of ordinary skill in the art upon reading the above description.

Claims

1. A computing system for implementing an Application Programming Interface (API) gateway, the computing system comprising: At least one hardware processor programmed to perform operations, the operations including: Receiving, by the API gateway, an API call directed to an exposed API associated with a backend system; Executing, by the API gateway, a computerized model trained at least in part based on the API call and at least in part based on API call context data associated with the API call; Determining, by the API gateway, a routing action for the API call at least in part based on an output of the trained computerized model; and Executing, by the API gateway, the routing action for the API call.

2. The computing system according to claim 1, wherein the routing action for the API call includes routing the API call to a first server associated with the exposed API.

3. The computing system according to claim 1, wherein the routing action for the API call includes rejecting the API call.

4. The computing system according to claim 1, wherein the routing action for the API call includes routing the API call to an exposed API having first content data, the first content data describing first content to be returned in response to the API call.

5. The computing system according to claim 1, wherein the output of the trained computerized model indicates a first authentication process, and the routing action for the API call includes: Determining that the API call passes the authentication process; And After determining that the API call passes the authentication process, routing the API call to the exposed API.

6. The computing system according to claim 1, wherein the routing action for the API call includes routing the API call to a version of the exposed API indicated by an output of the trained computerized model.

7. The computing system according to claim 1, wherein the output of the trained computerized model indicates an error response associated with the API call, and the operations further include: Detecting, by the API gateway, an error associated with the exposed API; And Executing an error response, the executing the error response including rejecting the API call or routing the API call to at least one of a backup server associated with the exposed API.

8. The computing system according to claim 1, wherein the API call context data includes origin user data describing an origin user associated with the API call, the origin user data including at least one of user history data describing past API calls made by the origin user, user preference data describing at least one preference of the origin user, or user account data describing an account of the origin user.

9. The computing system according to claim 1, wherein the API call context data includes network load data describing a load of at least one network between the API gateway and the exposed API.

10. The computing system according to claim 1, wherein the API call context data includes communication session data describing a type of communication session associated with the API call.

11. The computing system according to claim 1, wherein the API call context data includes geographic data describing the geographic location from which the API call originated.

12. The computing system according to claim 1, wherein the API call context data includes network data describing the network from which the API call originated.

13. The computing system according to claim 1, wherein the API call context data includes version data describing the version of the sending application associated with the API call.

14. The computing system according to claim 1, wherein the API call context data includes time data describing the time of day when the API call was made.

15. A method of operating an application programming interface (API) gateway, the method comprising: receiving, by the API gateway, an API call directed to an exposed API associated with a backend system; executing, by the API gateway, a trained computerized model based at least in part on the API call and at least in part on API call context data associated with the API call; determining, by the API gateway, a routing action for the API call based at least in part on the output of the trained computerized model; and executing, by the API gateway, the routing action for the API call.

16. The method according to claim 15, wherein the routing action for the API call includes routing the API call to a first server associated with the exposed API.

17. The method according to claim 15, wherein the routing action for the API call includes rejecting the API call.

18. The method according to claim 15, wherein the routing action for the API call includes routing the API call to an exposed API having first content data, the first content data describing first content to be returned in response to the API call.

19. The method according to claim 15, wherein the output of the trained computerized model indicates a first authentication process, and the routing action for the API call includes: determining that the API call passes the authentication process; and after determining that the API call passes the authentication process, routing the API call to the exposed API.

20. A non-transitory machine-readable medium having instructions thereon that, when executed by at least one hardware processor, cause the at least one hardware processor to perform operations, the operations including: receiving an API call directed to an exposed API associated with a backend system; executing a trained computerized model based at least in part on the API call and at least in part on API call context data associated with the API call; determining a routing action for the API call based at least in part on the output of the trained computerized model; and executing the routing action for the API call.

Images