Application Programming Interface Specification Generator

Abstract

Disclosed herein are system, method, and computer program product embodiments for automatically generating an application programming language (API) specification for an API. An embodiment operates by receiving an identification an API and a specification format for the identified API. The embodiment receives, via an API gateway, an API request that includes a first set of attributes for the API. The embodiment then receives an API response that includes a second set of attributes in response to the API request. The embodiment further determines whether the API request is valid based on at least one of the API request and the API response. In response to the API request being valid, the embodiment generates an API specification for the API using the specification format. The API specification includes a third set of attributes generated based on the first and second sets of attributes.

Description

CROSS-REFERENCE TO RELATED APPLICATIONS

This application claims the benefit of U.S. Provisional Patent Application No. 63/246,137 by Bispo, et al., titled “Enterprise Management Functionality in an Application Programming Interface Gateway,” filed on Sep. 20, 2021, which is incorporated by reference herein in its entirety.

BACKGROUND

One or more implementations relate to the field of Application Programming Interfaces (APIs), and more specifically, to API specification generation.

As connectivity between computer and mobile devices continues to develop, applications have been developed that communicate and share information. Commonly, applications may communicate via an Application Programming Interface (API). An API is a software interface offering a service to other programs to communicate data. APIs may have several different components, such as specifications, markdown documents, etc., that constitute part of an API's development.

An API gateway is an API management tool that sits between API users and backend services, transmitting API requests from API users to appropriate services provided by API endpoints and transmitting API responses back to API users for requested services. The API gateway can manage APIs and organization assets for companies providing various services to API users. A company may have hundreds or thousands of heterogeneous APIs deployed on different technology stacks, for example, the company may acquire other companies and their APIs and technologies to meet growing business demands. Some of the APIs may not be documented with API specifications or maintained up-to-date with changes and subsequent deployments. Without properly documented and maintained API specifications, the company may need to invest substantial time and resources to manage the APIs and provide appropriate services with the APIs, and may need to re-develop new APIs covered by existing APIs that are not documented.

BRIEF DESCRIPTION OF THE DRAWINGS

The accompanying drawings, which are incorporated herein and form a part of the specification, illustrate embodiments of the present disclosure and, together with the description, further serve to explain the principles of the disclosure and to enable a person skilled in the arts to make and use the embodiments.

FIG. 1 illustrates a block diagram of an exemplary environment for implementing an exemplary API policy chain to enable API specification generation, in accordance with some embodiments.

FIG. 2A illustrates a block diagram of an API specification generator, in accordance with some embodiments.

FIG. 2B illustrates a block diagram of API specification generation based on API requests and API responses, in accordance with some embodiments.

FIG. 2C illustrates a flowchart diagram of an exemplary method for generating API specification based on API requests and API responses, according to some embodiments.

FIG. 3 illustrates a flowchart diagram of an exemplary method for generating API specification for an API according to a specification format for the API, according to some embodiments.

FIG. 4 depicts an example computer system useful for implementing various embodiments.

In the drawings, like reference numbers generally indicate identical or similar elements. Additionally, generally, the left-most digit(s) of a reference number identifies the drawing in which the reference number first appears.

DETAILED DESCRIPTION

Provided herein are system, apparatus, device, method and/or computer program product embodiments, and/or combinations and sub-combinations thereof, for automatically generating API specifications for APIs.

An API is associated with an endpoint, i.e., a resource (often represented as a unique URL) that may accept API requests to the services provided by the particular API. APIs provide an additional level of security for both the client/requestor and server/responder because limited types of communications transmit between the client and server, obviating the need for any party to fully expose its data. An API can have multiple instances in various environments to process the API requests.

An API gateway authenticates and routes API requests and enforces rate limiting, throttling, and other service level agreements to protect the healthiness of the API and ensure that every internal component (servers, databases, etc) has capacity to serve the API requests. API gateways point to the backend API endpoints and services that a service provider defines, and abstracts them into a layer that can be regulated by an API management solution. The API gateway protects an organization's data by implementing encryption and access control. An API gateway uses “policies” to enforce regulations related to security, traffic control, authentication, access, and service level access. Generally speaking, a policy configures the desired behavior of the API gateway across a range of behaviors. The policy may be represented in YAML, JSON, or other suitable human-readable and machine interpretable format.

An API specification of an API defines the API functions and the results to expect for an API when using the API. The API specification can include various attributes to document and define the API, for example, API requests and responses payloads, API requests and responses headers, resources (e.g., endpoints), resource paths, and parameters for the resources.

In one example, to meet business demands, a company may acquire other companies and their infrastructures, ways of deployment, set of APIs, and technologies. With the acquisition, the company may need to onboard the set of APIs to its API gateway. A company may need to update API documentation and API management for other reasons, such as lack of maintenance. The API gateway may have a defined process to scale up the company's APIs, for example, first starting with the API specifications and then going to the deployment. However, some of the APIs may not be documented with API specifications. As a result, the endpoints associated with these APIs may be unprotected and these APIs may not be onboarded to the API gateway. Technical debt and a complex catch-up may be required in development processes for the company to figure out the expected payloads and/or endpoints of the APIs. The company may even need to re-develop new APIs covered by these APIs. Additionally, the company may have hundreds or thousands of heterogeneous APIs deployed on different technology stacks. Some of the company's existing APIs may not be maintained up-to-date with changes and subsequent deployments. Without properly-documented and well-maintained API specifications, a company may have a great challenge to manage the APIs and provide appropriate services to API users.

Accordingly, a need exists for automatically generating API specifications for the APIs in order to improve API management. In some embodiments, an API can be identified for specification generation with a specific format. In some embodiments, an API specification can be documented using a format such as RESTful API modeling language (RAML), open API specification (OAS), simple object access protocol (SOAP), and web application description language (WSDL). An API specification generator can be applied to the API as a policy in an API gateway. The API specification generator can act as a proxy to the API and intercept the traffic between the API users and the backend service. After receiving the API requests, the API specification generator can store the resource path being queried, the payload structure, and headers in the API requests. Once the backend service responds to the API requests with API responses, the API specification generator can receive and store the status codes, the payload structure, and headers in the API responses. The API specification generator can automatically generator an API specification for the API using the specific format based on the API requests and the API responses. With the API specification generator, API specifications can be automatically generated and documented for the APIs and changes to the APIs can be timely updated in the API specifications. Additionally, the API specifications can be generated in a specific format identified by the company and the generated API specification can be consistent with other existing API specifications across the company. The API specification generator can greatly reduce company resources for onboarding and managing APIs, minimize operational interruptions and maintenance effort, and improve customer experience of provided services.

Various embodiments of these features will now be discussed with respect to the corresponding figures.

FIG. 1 illustrates a block diagram of an exemplary environment 100 for implementing an exemplary API policy chain to enable API specification generation, in accordance with some embodiments. As illustrated in FIG. 1, environment 100 may include API users 112, API gateway 110, backend 118, and API management system 130.

API users 112 may be individuals or computer programs sending API request 122 to API endpoints 120 on backend 118 for a requested service and receiving API response 124 for the requested service. For example, API users 112 may be members of a business, organization, or other suitable group that are accessing API endpoints 120 using suitable computing systems, such as mobile devices and laptops. One skilled in the relevant arts will appreciate the wide range of computer applications that may access a provided API. API users 112 may access API endpoints 120 using a personal digital assistant, desktop workstation, laptop or notebook computer, netbook, tablet, smart phone, mobile phone, smart watch or other wearable, appliance, part of the Internet-of-Things, and/or embedded system, to name a few non-limiting examples, or any combination thereof. API users 112 may be human beings, but API users 112 may also be artificial intelligence constructs or other computer systems programmatically accessing API endpoints 120. API users 112 may employ, i.e., connect to, a network or combination of networks including the Internet, a local area network (LAN), a wide area network (WAN), a wireless network, a cellular network, or various other types of networks as would be appreciated by a person of ordinary skill in the art. In some embodiments, API request 122 and API response 124 can include multiple attributes as described in detail below in FIG. 2B.

API gateway 110 may abstract API endpoints 120 into APIs and provide gateway capabilities over the APIs, execute out-of-the-box policies, and extend the out-of-the-box policy suite with custom policies defined by a customer. As shown in FIG. 1, API gateway 110 can include a listener 102, an API X policy chain 104, a router 106, and a storage 116. Listener 102 may act as an interface between API users 112 and API gateway 110. Router 106 may act as an interface between API gateway 110 and backend 118 and may forward API request 122 to appropriate API endpoints 120 in backend 118.

API gateway 110 may apply throttling, security, caching, and logging to an organization's APIs. API gateway 110 may be configured to receiving incoming API request 122 from API users 112 and providing corresponding API response 124 to API users 112. API gateway 110 may authenticate and route API requests 122 to backend 118. API gateway 110 may enforce rate limiting, throttling, and other service level agreements. API gateway 110 may implement encryption and access control. API gateway 110 may use policies to enforce these various regulations related to security, traffic control, authentication, access, and service level access. An API policy may be a set of rules that are enforced by API Gateway 110. In some embodiments, some API policies may allow or block access to APIs based on an IP address of the client application in API users 112, while others may allow or restrict access to specific resources provided by an API. Some API policies may enable controlling the rate at which API requests are made to a backend API. Further, an API policy may be an out-of-the-box policy defined by an API gateway provider or a custom policy defined by a customer using API gateway 110.

API gateway 110 may implement one or more policy chains corresponding to one or more APIs to enforce these regulations. For example, as shown in FIG. 1, API gateway 110 can implement policy chain 104 corresponding to API X. Listener 102 may receive API request 122 corresponding to API X. API gateway 110 may apply API X policy chain 104 to API request 122. API X policy chain 104 may include client ID enforcement 104a, rate-limiting 104b, and API spec generator 108. In some embodiments, client ID enforcement 104a may validate a client before accessing backend 118. In some embodiments, rate-limiting 104b may limit the number of times API users 112 may send a request to an API within a specific time period in order to mitigate denial of service attacks. In some embodiments, API spec generator 108 may be implemented as a policy in API gateway 110 to generate an API specification for the API. In some embodiments, API spec generator 108 may be applied to an API separately out of any policy chains. API spec generator 108 can act as a proxy to one or more APIs and intercept the traffic between API users 112 and backend 118. In some embodiments, API spec generator 108 can further include a machine learning module 114 and other modules, as described in detail below in FIG. 2A. In some embodiments, API gateway 110 may determine whether API request 122 is valid based on attributes in API request 122. For example, if API users 112 do not have access to API endpoints 120 in back end 118 (e.g., access limited by client ID enforcement 104a), API gateway 110 may not process and route API request 122 from API users 112 to backend 118 and may notify API users 112 that API request 122 is not valid.

API spec generator 108 can store API request 122 received from API users 112 and API response 124 received from backend 118 in storage 116. In some embodiments, storage 116 can include means, devices, components, instrumentalities or approaches for allowing instructions and/or data to be accessed by API spec generator 108. In some embodiments, storage 116 can include one or more databases or other data storage structures. In some embodiments, storage 116 can include one or more data storage devices, such a hard drive and a removable storage drive, as described in detail below in FIG. 4.

Backend 118 can include API endpoints 120 providing services to API users 112. API endpoints 120 may be associated with managed APIs. In general terms, an API facilitates communication between two software applications. API endpoints 120 may represent resources and may be a unique URL to each resource. API endpoints 120 may accept API request 122 to the services provided by the particular API. One skilled in the arts will recognize that many arrangements exist having multiple API endpoints 120 for various APIs to accommodate a far-ranging variety of use cases.

API management system 130 may include an API manager 132 and may allow an API owner or a customer to configure, manage, govern, and secure APIs. In some embodiments, API management system 130 may include Anypoint Exchange platform provided by MuleSoft. In some embodiments, API management system 130 may be a hypertext transfer protocol (HTTP) service hosted in Heroku or other service providers alike. In some embodiments, API management system 130 may allow the API owner or customer to secure APIs with policies as described above. API management system 130 may store or have access to API specification 134 for each of the APIs and API manager 132 may allow the API owner or customer to edit, change, or update API specification 134. API specification 134 may define the API functions and the results to expect for an API when using the API. API specification 134 can include multiple attributes to document and define the API, as described in detail below in FIG. 2B. In some embodiments, API specification 134 can be documented using a specific format or language, such as RAML, OAS, SOAP, and WSDL. In some embodiments, API manager 132 may allow the API owner or customer to identify or select a specification format for an API.

API management system 130 may also manage client access, group APIs into products, and provide analytics and insights into the behavior of configured APIs. For example, API management system 130 may allow the API owner or customer to add a new API instance for the generated API specification 134, provide credentials, search for managed APIs, etc. API management system 130 may allow the API owner or customer to enforce service level agreements, e.g., by providing service level access tiers to limit the number of requests that any particular API users 112 may make to a particular API. API management system 130 may provide a GUI through which the API owner or customer may configure the applications. API management system 130 may provide capabilities to offer a service mesh to enforce consistent security across micro-services from a single, centralized location.

FIG. 2A illustrates a block diagram of API spec generator 108, in accordance with some embodiments. In some embodiments, as shown in FIG. 2A, API spec generator 108 can include machine learning module 114, an API request monitor 202, an API response monitor 204, an endpoint identifier 206, and an API category labeler 208. FIG. 2B illustrates a block diagram of a specification generating mechanism for API specification 134 based on API request 122 and API response 124, in accordance with some embodiments. As shown in FIG. 2B, API request 122 may include a first set of attributes, such as attribute 222 and attribute 224. In some embodiments, attributes 222 and 224 can include request information and format for API endpoints 120, such as API request payloads, API request headers, resources (e.g., API endpoints 120), resource paths, parameters of the resources, and other attributes for API request 122. API response 124 may include a second set of attributes, such as attribute 226 and attribute 228. In some embodiments, attributes 226 and 228 can include response information and format for API request 122, such as API response payloads, API response headers, status codes, and other attributes for API response 124. API specification 134 may include a third set of attributes, such as attribute 234 and attribute 236. In some embodiments, attributes 234 and 236 can include API request and response payloads, API request and response headers, resources, resource paths, parameters for the resources, status codes and other attributes for the API.

In some embodiments, status codes in API response 124 may indicate whether API request 122 is valid. For example, an HTTP status code in API response 124 can indicate whether API request 122 is valid. If the value of the HTTP status code in API response 124 is in the form of 2xx, the corresponding API request 122 is valid. While FIG. 2B illustrates that each of API request 122, API response 124, and API specification 134 has only two attributes, this is done merely for simplicity of explanation. One skilled in the arts will recognize that API request 122, API response 124, and API specification 134 may have one or more attributes.

In some embodiments, API request monitor 202 may monitor API request 122 from API users 112 for an API, such as API X as shown in FIG. 1. API request monitor 202 may receive API request 122 and attributes 222 and 224 in API request 122. API request monitor 202 may store attributes 222 and 224 of received API request 122 in storage 116 as shown in FIG. 1. In some embodiments, API response monitor 204 may monitor API response 124 from backend 118 in response to API request 122. API response monitor 204 may receive API response 124 and attributes 226 and 228 in API response 124. API response monitor 204 may store API response 124 in storage 116 as shown in FIG. 1. In some embodiments, API request monitor 202 and API response monitor 204 may continuously monitor and store API request 122 and API response 124 transmitting between API users 112 and backend 118. API spec generator 108 may continuously update the generated API specification 134 according to the received API request 122 and API response 124. In some embodiments, an API owner or a customer may set up a period of time for API spec generator 108 to generate API specification 134 for an API. The API owner or customer may stop generating/updating API specification 134 for the API after the period of time. Endpoint identifier 206 may identify API endpoints 120 in backend 118 related to API request 122 and API response 124.

API category labeler 208 may add comments in API specification 134 for an API and label the API with a category label based on the headers in API request 122 and API response 124. The category label may include category information of the API. In some embodiments, API request monitor 202 may parse the attributes in API request 122 to obtain information in the API request headers. Similarly, API response monitor 204 may parse the attributes in API response 124 to obtain information in the API response headers. For example, API request 122 for an API may include authorization headers, which may indicate that the API has a security scheme. Accordingly, API category labeler 208 may add a comment on the security scheme of the API in API specification 134 and label the API with a category label of security authorization API. In another example, API response 124 for an API may include rate-limiting headers, which may indicate that the API is using rate-limiting to protect the services provided by the API. API category labeler 208 may add a comment on the rate-limiting of the API in API specification 134 and label the API with a category label of rate-limiting API. The comments in API specification 134 added by API category labeler 208 and the category labels for the APIs can improve the API documentation process and customer management of the APIs.

In some embodiments, API spec generator 108 can use machine learning module 114 to generation API specification 134 for an API based on received API request 122 and API response 124. In some embodiments, machine learning module 114 can include or have access to at least one predefined API specification 212. Predefined API specification 212 can include one or more predefined attributes, such as predefined attributes 214 and 216, and one or more predefined rules, such as predefined rule 218. In some embodiments, predefined API specification 212 can include existing API specifications for APIs managed by API gateway 110. In some embodiments, predefined API specification 212 can be defined by a customer using API gateway 110 to include predefined attributes 214 and 216 and predefined rule 218.

Predefined attributes 214 and 216 may include standard attributes for an API and predefined rule 218 may include standard rules about how the API responds to a request. For example, predefined attributes 214 and 216 may include operations to perform for an API, such as POST and PATCH. POST can be used for creating a resource (e.g., API endpoints 120) and PATCH can be used for updating the resource. POST and PATCH can be standard attributes to create and manage a resource. In another example, predefined rule 218 may include an HTTP standard. According to the HTTP standard, if API response 124 includes an “etag” header from backend 118, API response 124 may include status code 304 or 412. Status code 304 may indicate that a conditional GET or HEAD request operation has been received and would have resulted in a 200 (OK) response if the condition is not evaluated to false. Statue code 412 may indicate that one or more conditions given in the request headers are evaluated to false. With predefined attributes 214 and 216 and predefined rule 218, API spec generator 108 can predict additional requests and responses for the API and add additional attributes corresponding to the predicted API requests and responses to the generated API specification 134 for the API.

In some embodiments, API spec generator 108 may continuously collect attributes in received API request 122 and API response 124 for an API to generate and update API specification 134 for the API, as shown in FIGS. 1, 2A, and 2B. In some embodiments, as shown in FIG. 2A, API spec generator 108 may use machine learning module 114 to analyze the attributes in received API request 122 and API response 124 for an API, compare the received attributes with predefined attributes 214 and 216 in one or more predefined API specifications, and identify one predefined API specification 212 for the API. The identified predefined API specification 212 can be stored as API specification 134 in API management system 130 for further edit and update.

In some embodiments, machine learning module 114 can identify additional endpoints or resources related to the API based on predefined attributes 214 and 216 in predefined API specification 212. For example, predefined API specification 212 may include additional endpoints that have not been frequently or ever requested by API request 122. Machine learning module 114 may determine a probability of the existence of the additional endpoints. For example, if most predefined API specifications 212 (e.g., about 90%) include the additional endpoints 120, API spec generator 108 can determine a high probability (e.g., about 90%) of the existence of the additional endpoints and can add the additional endpoints to the generated API specification 134.

In some embodiments, machine learning module 114 can identify additional operations of endpoints 120 related to the API based on predefined API specification 212. In another example, if most of the endpoints in predefined API specification 212 have both POST and PATCH operations while one specific endpoint 120 for the API just have a POST operation (e.g., determined from received API request 122 and API response 124), machine learning module 114 may determine that the specific endpoint 120 may also have a PATCH operation and may add the missing PATCH operation into generated API specification 134 for the API.

In some embodiments, API spec generator 108 may monitor and collect API request 122 and API response 124 for a period of time. An API owner or a customer may set up the period of time, such as six months, and stop generating/updating API specification 134 after the period of time. In some embodiments, the API owner or customer may start/stop generation API specification 134 by enabling/disenabling a policy corresponding to API spec generator 108 in API gateway 110. In some embodiments, if a number of API request 122 received in the period of time for a specific API corresponding to API endpoints 120 is less than a threshold, such as one, API manager 132 in API management system 130 may remove corresponding API specification 134 for the specific API. As a result, maintenance effort of the API and API specification 134 can be minimized.

In some embodiments, API spec generator 108 may partition a large API specification into a number of smaller component API specifications for one API. For example, the large API may handle multiple topics and provide services with various API endpoints 120. API spec generator 108 may identify related API endpoints 120 for the large API with endpoint identifier 206. Machine learning module 114 may collect and inspect the payloads and request/response parameters of API request 122 and API response 124 for the related API endpoints. Machine learning module 114 may divide the related API endpoints 120 into a number of endpoint groups based on the payloads and request/response parameters of API request 122 and API response 124. Each endpoint group may have similar endpoints 120 handling a same topic. For example, endpoints 120 in each endpoint group may have one or more common attributes. Accordingly, API spec generator 108 may split the large API specification for the large API into multiple smaller component API specifications according the endpoint groups. The number of the smaller component API specifications can corresponding to the number of endpoint groups. Each component API specification corresponding to one of the endpoint groups. The smaller component API specifications can be stored as API specification 134 and can be further edited or updated by API manager 132 in API management system 130. In this way, maintenance effort of API specification 134 can be minimized and API management can be improved.

In some embodiments, API spec generator 108 may generate API specification 134 for HTTP APIs. In some embodiments, API spec generator 108 may generate API specification 134 for other APIs, such as graph query language (GraphQL) APIs. API spec generator 108 may recognize a GraphQL API and check each API request 122 to ensure a same resource path for API request 122. API spec generator 108 may generate API specification 134 for the GraphQL API in an appropriate specification format.

FIG. 2C illustrates a flowchart diagram of an exemplary method 200 for generating API specification based on API requests and API responses, according to some embodiments. Method 200 can be performed by processing logic that can comprise hardware (e.g., circuitry, dedicated logic, programmable logic, microcode, etc.), software (e.g., instructions executing on a processing device), or a combination thereof. It is to be appreciated that not all steps may be needed to perform the disclosure provided herein. Further, some of the steps may be performed simultaneously, or in a different order than shown in FIG. 2C, as will be understood by a person of ordinary skill in the art.

Method 200 shall be described with reference to FIGS. 1 and 2A-2B. However, method 200 is not limited to those example embodiments.

In step 210, an API request that includes a first set of attributes for an API is received via an API gateway. For example, as shown in FIG. 1, API request 122 for API X from API users 112 is received via API gateway 110. Listener 102 may act as an interface between API users 112 and API gateway 110 and may receive API request 122 corresponding to API X. API request 122 may include multiple attributes, such as attributes 222 and 224 shown in FIG. 2B. In some embodiments, attributes 222 and 224 can include API request payloads, API request headers, resources (e.g., API endpoints 120), resource paths, parameters for the resources, and other attributes for API request 122. In some embodiments, one or more policies may be applied to the received API request 122 to enforce various regulations related to security, traffic control, authentication, access, and service level access, for example, client ID enforcement 104a, rate limit 104b, and API spec generator 108.

In step 220, the first set of attributes of the API request is obtained. For example, as shown in FIGS. 1 and 2A-2B, API spec generator 108 can receive attributes 222 and 224 in API request 122 and store them in storage 116. In some embodiments, API request monitor 202 in API spec generator 108 can monitor and obtain attributes 222 and 224. In some embodiments, API request monitor 202 may continuously monitor and store API request 122 for a period of time set up by an API owner or a customer. Router 106 may act as an interface between API gateway 110 and backend 118 and may route API request 122 to corresponding API endpoints 120 in backend 118.

In step 230, an API response that includes a second set of attributes in response to the API request is received. For example, as shown in FIGS. 1 and 2A-2B, API response 124 in response to API request 122 is received by router 106 at API gateway 110. API response 124 may include multiple attributes, such as attributes 226 and 228 shown in FIG. 2B. In some embodiments, attributes 226 and 228 can include API response payloads, API response headers, status codes, and other attributes for API response 124.

In step 240, the second set of attributes of the API response is obtained. For example, as shown in FIGS. 1 and 2A-2B, API spec generator 108 can receive attributes 226 and 228 of API response 124 and store them in storage 116. In some embodiments, API response monitor 204 in API spec generator 108 can monitor and obtain attributes 226 and 228. In some embodiments, API response monitor 204 may continuously monitor and store API response 124 for a period of time set up by an API owner or a customer.

In step 250, an API specification for the API is generated based on the first and second sets of attributes. For example, as shown in FIGS. 1 and 2A-2B, API spec generator 108 can generate API specification 134 for the API based on received attributes 222, 224, 226, and 228 in API request 122 and API response 124. In some embodiments, API spec generator 108 can generate attributes 234 and 236 for API specification 134 with the received attributes 222, 224, 226, and 228. In some embodiments, API spec generator 108 may add attributes 222, 224, 226, and 228 to API specification 134. The generated API specification 134 can be stored in API management system 130 and can be further edited or updated by the API owner or customer via API manager 132. In some embodiments, API spec generator 108 may use machine learning module 114 to analyze the received attributes 222, 224, 226, and 228 in API request 122 and API response 124, compare the received attributes with predefined attributes 214 and 216 in one or more predefined API specifications, and identify one predefined API specification 212 for the API. The identified predefined API specification 212 can be stored as API specification 134 in API management system 130 for further edit and update. As a result, company resources can be reduced to onboard and mange APIs.

With machine learning module 114, additional API endpoints 120 related to the API and additional attributes for API specification 134 can be identified and added to API specification 134. Additionally, machine learning module 114 can identify APIs that are not frequently requested or never requested and corresponding API specification 134 for these APIs can be removed to minimize maintenance effort and improve customer service.

FIG. 3 illustrates a flowchart diagram of an exemplary method 300 for generating API specification for an API according to a specification format for the API, according to some embodiments. Method 300 can be performed by processing logic that can comprise hardware (e.g., circuitry, dedicated logic, programmable logic, microcode, etc.), software (e.g., instructions executing on a processing device), or a combination thereof. It is to be appreciated that not all steps may be needed to perform the disclosure provided herein. Further, some of the steps may be performed simultaneously, or in a different order than shown in FIG. 3, as will be understood by a person of ordinary skill in the art.

Method 300 shall be described with reference to FIGS. 1 and 2A-2C. However, method 300 is not limited to those example embodiments.

In step 310, an identification of an API and a specification formation for the identified API is received. For example, as shown in FIG. 1, API spec generator 108 can receive an identification of an API and a specification format for the identified API from API management system 130. An API owner or a customer may request generation of an API specification for the API and may identify the API via API manager 132. The API owner or customer may also identify a specification format for the requested API specification. In some embodiments, an API specification can be documented using a format such as RAML, OAS, SOAP, and WSDL. In some embodiments, the API owner or customer may identify and select via API manager 312 a specification format the same as that of existing API specifications. Accordingly, the generated API specification can have a consistent format with the existing API specifications. In some embodiments, the API owner or customer may specify via API manager 312 a specification format needed for the identified API.

In step 320, an API request that includes a first set of attributes for the API is received via an API gateway. For example, as shown in FIGS. 1 and 2A-2B, API request 122 for API X from API users 112 can be received via API gateway 110. API request 122 may include multiple attributes, such as attributes 222 and 224 as shown in FIG. 2B. In some embodiments, step 320 can be similar to step 210 in FIG. 2C. Listener 102 may receive API request 122 corresponding to API X. In some embodiments, API spec generator 108 may be applied to API X via API X policy chain 104 to receive API request 122. API request monitor 202 in API spec generator 108 can monitor and obtain attributes 222 and 224 and store them in storage 116. In some embodiments, API request monitor 202 may continuously monitor and store API request 122 for a period of time set up by an API owner or a customer. Router 106 may act as an interface between API gateway 110 and backend 118 and may route API request 122 to corresponding API endpoints 120 in backend 118.

In step 330, an API response that includes a second set of attributes in response to the API request is received. For example, as shown in FIGS. 1 and 2A-2B, API response 124 in response to API request 122 can be received by router 106 at API gateway 110. API response 124 may include multiple attributes, such as attributes 226 and 228 as shown in FIG. 2B. In some embodiments, step 330 can be similar to step 230 in FIG. 2C. In some embodiments, API response monitor 204 in API spec generator 108 can monitor API response 124, obtain attributes 226 and 228, and store them in storage 116. In some embodiments, API response monitor 204 may continuously monitor and store API response 124 for a period of time set up by an API owner or a customer.

In step 340, the API request is determined if valid based on at least one of the API request and the API response. For example, as shown in FIGS. 1 and 2A-2B, API gateway 110 can determine whether API request 122 is valid based on at least one of API request 122 and API response 124. In some embodiments, API gateway 110 may determine whether API request 122 is valid based on attributes 222 and 224 in API request 122. For example, if API users 112 do not have access to API endpoints 120 in backend 118, API gateway 110 may not process and route API request 122 to backend 118 and may notify API users 112 that API request 122 is not valid. In some embodiments, status codes in API response 124 may indicate whether API request 122 is valid. For example, if the value of an HTTP status code in API response 124 is in the form of 2xx, the corresponding API request 122 is valid.

In step 350, method 300 proceeds based on whether the API request is valid. As shown in FIG. 3, if API request 122 is valid, method 300 can proceed to step 360 to generate an API specification for the API. If API request 122 is not valid, method 300 can proceed to step 320 to receive additional API requests for the API.

In step 360, an API specification for the API is generated using the specification format and based on the first and second sets of attributes. For example, as shown in FIGS. 1 and 2A-2B, API spec generator 108 can generate API specification 134 for the API using the identified specification format and based on received attributes 222, 224, 226, and 228. In some embodiments, step 360 can be similar to step 250 in FIG. 2C.

In some embodiments, API spec generator 108 can continuously monitor and store API request 122 and API response 124 for a period of time set up by an API owner or a customer via API manager 132. In some embodiments, API spec generator 108 can generate and update API specification 134 based on the received attributes 222, 224, 226, and 228 for the period of time. In some embodiments, API spec generator 108 may add attributes 222, 224, 226, and 228 to API specification 134. The generated API specification 134 can be stored in API management system 130 and can be further edited or updated by the API owner of customer via API manager 132. In some embodiments, API spec generator 108 may use machine learning module 114 to analyze the received attributes 222, 224, 226, and 228 in API request 122 and API response 124, compare the received attributes with predefined attributes 214 and 216 in one or more predefined API specifications, and identify one predefined API specification 212 for the API. The identified predefined API specification 212 can be stored as API specification 134 in API management system 130 for further edit and update. With API spec generator 108, company resources for onboarding and managing APIs can be reduced, operational interruptions and maintenance effort can be minimized, and customer experience of provided services can be improved.

Various embodiments may be implemented, for example, using one or more well-known computer systems, such as computer system 400 shown in FIG. 4. One or more computer systems 400 may be used, for example, to implement any of the embodiments discussed herein, as well as combinations and sub-combinations thereof.

Computer system 400 may include one or more processors (also called central processing units, or CPUs), such as a processor 404. Processor 404 may be connected to a communication infrastructure or bus 406.

Computer system 400 may also include user input/output device(s) 403, such as monitors, keyboards, pointing devices, etc., which may communicate with communication infrastructure 406 through user input/output interface(s) 402.

One or more of processors 404 may be a graphics processing unit (GPU). In an embodiment, a GPU may be a processor that is a specialized electronic circuit designed to process mathematically intensive applications. The GPU may have a parallel structure that is efficient for parallel processing of large blocks of data, such as mathematically intensive data common to computer graphics applications, images, videos, etc.

Computer system 400 may also include a main or primary memory 408, such as random access memory (RAM). Main memory 408 may include one or more levels of cache. Main memory 408 may have stored therein control logic (i.e., computer software) and/or data.

Computer system 400 may also include one or more secondary storage devices or memory 410. Secondary memory 410 may include, for example, a hard disk drive 412 and/or a removable storage device or drive 414. Removable storage drive 414 may be a floppy disk drive, a magnetic tape drive, a compact disk drive, an optical storage device, tape backup device, and/or any other storage device/drive.

Removable storage drive 414 may interact with a removable storage unit 418. Removable storage unit 418 may include a computer usable or readable storage device having stored thereon computer software (control logic) and/or data. Removable storage unit 418 may be a floppy disk, magnetic tape, compact disk, DVD, optical storage disk, and/any other computer data storage device. Removable storage drive 414 may read from and/or write to removable storage unit 418.

Secondary memory 410 may include other means, devices, components, instrumentalities or other approaches for allowing computer programs and/or other instructions and/or data to be accessed by computer system 400. Such means, devices, components, instrumentalities or other approaches may include, for example, a removable storage unit 422 and an interface 420. Examples of the removable storage unit 422 and the interface 420 may include a program cartridge and cartridge interface (such as that found in video game devices), a removable memory chip (such as an EPROM or PROM) and associated socket, a memory stick and USB port, a memory card and associated memory card slot, and/or any other removable storage unit and associated interface.

Computer system 400 may further include a communication or network interface 424. Communication interface 424 may enable computer system 400 to communicate and interact with any combination of external devices, external networks, external entities, etc. (individually and collectively referenced by reference number 428). For example, communication interface 424 may allow computer system 400 to communicate with external or remote devices 428 over communications path 426, which may be wired and/or wireless (or a combination thereof), and which may include any combination of LANs, WANs, the Internet, etc. Control logic and/or data may be transmitted to and from computer system 400 via communication path 426.

Computer system 400 may also be any of a personal digital assistant (PDA), desktop workstation, laptop or notebook computer, netbook, tablet, smart phone, smart watch or other wearable, appliance, part of the Internet-of-Things, and/or embedded system, to name a few non-limiting examples, or any combination thereof.

Computer system 400 may be a client or server, accessing or hosting any applications and/or data through any delivery paradigm, including but not limited to remote or distributed cloud computing solutions; local or on-premises software (“on-premise” cloud-based solutions); “as a service” models (e.g., content as a service (CaaS), digital content as a service (DCaaS), software as a service (SaaS), managed software as a service (MSaaS), platform as a service (PaaS), desktop as a service (DaaS), framework as a service (FaaS), backend as a service (BaaS), mobile backend as a service (MBaaS), infrastructure as a service (IaaS), etc.); and/or a hybrid model including any combination of the foregoing examples or other services or delivery paradigms.

Any applicable data structures, file formats, and schemas in computer system 400 may be derived from standards including but not limited to JavaScript Object Notation (JSON), Extensible Markup Language (XML), Yet Another Markup Language (YAML), Extensible Hypertext Markup Language (XHTML), Wireless Markup Language (WML), MessagePack, XML User Interface Language (XUL), or any other functionally similar representations alone or in combination. Alternatively, proprietary data structures, formats or schemas may be used, either exclusively or in combination with known or open standards.

In some embodiments, a tangible, non-transitory apparatus or article of manufacture comprising a tangible, non-transitory computer useable or readable medium having control logic (software) stored thereon may also be referred to herein as a computer program product or program storage device. This includes, but is not limited to, computer system 400, main memory 408, secondary memory 410, and removable storage units 418 and 422, as well as tangible articles of manufacture embodying any combination of the foregoing. Such control logic, when executed by one or more data processing devices (such as computer system 400), may cause such data processing devices to operate as described herein.

Based on the teachings contained in this disclosure, it will be apparent to persons skilled in the relevant art(s) how to make and use embodiments of this disclosure using data processing devices, computer systems and/or computer architectures other than that shown in FIG. 4. In particular, embodiments can operate with software, hardware, and/or operating system implementations other than those described herein.

It is to be appreciated that the Detailed Description section, and not any other section, is intended to be used to interpret the claims. Other sections can set forth one or more but not all exemplary embodiments as contemplated by the inventor(s), and thus, are not intended to limit this disclosure or the appended claims in any way.

While this disclosure describes exemplary embodiments for exemplary fields and applications, it should be understood that the disclosure is not limited thereto. Other embodiments and modifications thereto are possible, and are within the scope and spirit of this disclosure. For example, and without limiting the generality of this paragraph, embodiments are not limited to the software, hardware, firmware, and/or entities illustrated in the figures and/or described herein. Further, embodiments (whether or not explicitly described herein) have significant utility to fields and applications beyond the examples described herein.

Embodiments have been described herein with the aid of functional building blocks illustrating the implementation of specified functions and relationships thereof. The boundaries of these functional building blocks have been arbitrarily defined herein for the convenience of the description. Alternate boundaries can be defined as long as the specified functions and relationships (or equivalents thereof) are appropriately performed. Also, alternative embodiments can perform functional blocks, steps, operations, methods, etc. using orderings different than those described herein.

References herein to “one embodiment,” “an embodiment,” “an example embodiment,” or similar phrases, indicate that the embodiment described can include a particular feature, structure, or characteristic, but every embodiment can not necessarily include the particular feature, structure, or characteristic. Moreover, such phrases are not necessarily referring to the same embodiment. Further, when a particular feature, structure, or characteristic is described in connection with an embodiment, it would be within the knowledge of persons skilled in the relevant art(s) to incorporate such feature, structure, or characteristic into other embodiments whether or not explicitly mentioned or described herein. Additionally, some embodiments can be described using the expression “coupled” and “connected” along with their derivatives. These terms are not necessarily intended as synonyms for each other. For example, some embodiments can be described using the terms “connected” and/or “coupled” to indicate that two or more elements are in direct physical or electrical contact with each other. The term “coupled,” however, can also mean that two or more elements are not in direct contact with each other, but yet still co-operate or interact with each other.

The breadth and scope of this disclosure should not be limited by any of the above-described exemplary embodiments, but should be defined only in accordance with the following claims and their equivalents.

Claims

1. A method, comprising:

receiving an identification of an application programming interface (API) and a specification format for the API;

receiving, via an API gateway, an API request that includes a first set of attributes for the API;

receiving an API response that includes a second set of attributes in response to the API request;

determining, based on at least one of the API request and the API response, whether the API request is valid; and

generating, in response to the API request being valid, an API specification for the API using the specification format, wherein the API specification comprises a third set of attributes generated based on the first and second sets of attributes.

2. The method of claim 1, wherein the generating of the API specification comprises adding the first and second sets of attributes to the API specification.

3. The method of claim 1, wherein the generating of the API specification comprises identifying a predefined API specification from a set of predefined API specifications using a machine-learning model based on the first and second sets of attributes.

4. The method of claim 3, further comprising identifying endpoints of the API based on the predefined API specification.

5. The method of claim 1, further comprising:

identifying endpoints responding to the API request;

dividing the endpoints into a number of groups, wherein the endpoints in each group share at least one common attribute; and

splitting the API specification into a plurality of component API specifications, each of the plurality of component API specifications corresponding to one of the groups.

6. The method of claim 1, further comprising:

determining a number of API requests received for the API in a period time; and

removing the API in response to the number of API requests being below a threshold.

7. The method of claim 1, further comprising:

identifying, based on a predefined rule for the API response, additional attributes related to an attribute in the second set of attributes; and

adding the additional attributes to the API specification.

8. The method of claim 1, further comprising:

determining a category label for the API based on the first and second sets of attributes; and

adding the category label to the API specification, wherein the category label includes category information of the API.

9. The method of claim 1, further comprising updating the API specification based on additional API requests and additional API responses for the API.

10. The method of claim 1, wherein the first set of attributes comprise API request payloads, API request headers, resources, resource paths, and parameters of the resources for the API request, and wherein the second set of attributes comprise API response payloads, API response headers, and status codes for the API response.

11. A system, comprising:

a memory; and

at least one processor coupled to the memory and configured to: receive an identification of an application programming interface (API) and a specification format for the API; receive, via an API gateway, an API request that includes a first set of attributes for the API; receive an API response that includes a second set of attributes in response to the API request; determine, based on at least one of the API request and the API response, whether the API request is valid; and generate, in response to the API request being valid, an API specification for the API using the specification format, wherein the API specification comprises a third set of attributes generated based on the first and second sets of attributes.

12. The system of claim 11, wherein to generate the API specification the at least one processor is configured to add the first and second sets of attributes to the API specification.

13. The system of claim 11, wherein to generate the API specification the at least one processor is configured to identify a predefined API specification from a set of predefined API specifications using a machine-learning model based on the first and second sets of attributes.

14. The system of claim 13, wherein the at least one processor is further configured to identify endpoints of the API based on the predefined API specification.

15. The system of claim 11, wherein the at least one processor is further configured to:

identify endpoints responding to the API request;

divide the endpoints into a number of groups, wherein the endpoints in each group share at least one common attributes; and

split the API specification into a plurality of API component specifications, each of the plurality of component API specification corresponding to one of the groups.

16. The system of claim 11, wherein the at least one processor is further configured to:

determine a number of API requests received for the API in a period time; and

remove the API in response to the number of API requests being below a threshold.

17. The system of claim 11, wherein the at least one processor is further configured to:

identify, based on a predefined rule for the API response, additional attributes related to an attribute in the second set of attributes; and

add the additional attributes to the API specification.

18. The system of claim 11, wherein the at least one processor is further configured to:

determining a category label for the API based on the first and second sets of attributes; and

adding the category label to the API specification, wherein the category label includes category information of the API.

19. A non-transitory computer-readable medium (CRM) having instructions stored thereon that, when executed by at least one computing device, causes the at least one computing device to perform operations comprising:

receiving an identification of an application programming interface (API) and a specification format for the API;

receiving, via an API gateway, an API request that includes a first set of attributes for the API;

receiving an API response that includes a second set of attributes in response to the API request;

determining, based on at least one of the API request and the API response, whether the API request is valid; and

generating, in response to the API request being valid, an API specification for the API using the specification format, wherein the API specification comprises a third set of attributes generated based on the first and second sets of attributes.

20. The non-transitory CRM of claim 19, further comprising:

identifying endpoints responding to the API request;

dividing the endpoints into a number of groups, wherein the endpoints in each group share at least one common attributes; and

splitting the API specification into a plurality of API specifications corresponding to the number of groups.