Abstract: Disclosed herein are system, method, and computer program product embodiments for automatically cataloging updated Application Programming Interface (API) specifications with updated version numbers. The API specifications may have been previously published to an application exchange platform. An automatic cataloging tool installed at an API development system may identify an updated API specification committed to an API specification repository. The automatic cataloging tool may identify a base API specification that has been previously published and confirm that a change has been made. The base API specification may correspond to a particular API development branch that has been updated. The automatic cataloging tool may also apply a versioning strategy to automatically determine an updated version number for the updated API specification. The application exchange platform may then replace the previous API specification with the updated API specification and the updated version number.

Abstract: Disclosed herein are system, method, and computer program product embodiments for providing asynchronous backend processing of complex, time consuming, and/or expensive jobs. A command line interface (CLI) provides a command interface between a user and a backend processing server. The CLI sends a job request to the backend server, which immediately replies to the request with a confirmation message that includes a job identifier. This response is sufficient to allow the CLI to end its wait for the job response. Meanwhile, the backend server carries out the job by parsing the job into component tasks according to a declaration file and assigns those different tasks to different work servers. The backend server functions as a master server, tracking the statuses of the different tasks and assigning out new tasks until the job is complete. An overall job status is provided to the CLI upon request by referencing the job identifier.

Abstract: Disclosed herein are system, method, and computer program product embodiments for automatically cataloging updated Application Programming Interface (API) specifications. The API specifications may have been previously published to an application exchange platform. An automatic cataloging tool installed at an API development system may identify an updated API specification committed to an API specification repository. To validate that a change has been made, the automatic cataloging tool may compare the updated specification, metadata, and/or referenced documentation files to an API specification previously posted to the application exchange platform. In response to determining that the API specifications differ, the automatic cataloging tool may transmit the updated API specification to the application exchange platform. The application exchange platform may then replace the previous API specification with the updated API specification for client devices to view.

Abstract: Disclosed herein are system, method, and computer program product embodiments for automatically cataloging updated Application Programming Interface (API) specifications with updated version numbers. The API specifications may have been previously published to an application exchange platform. An automatic cataloging tool installed at an API development system may identify an updated API specification committed to an API specification repository. The automatic cataloging tool may identify a base API specification that has been previously published and confirm that a change has been made. The base API specification may correspond to a particular API development branch that has been updated. The automatic cataloging tool may also apply a versioning strategy to automatically determine an updated version number for the updated API specification. The application exchange platform may then replace the previous API specification with the updated API specification and the updated version number.

Abstract: Disclosed herein are system, method, and computer program product embodiments for automatically discovering an API for publishing within a data repository. A discovery tool is used either on a server computer or a customer computer to examine the files stored in the data repository. A search of the repository is conducted to identify root API files that form the basis of an API. A first examination is conducted in which the files are examined for common indicia associated with known API standards. Then a second examination is done of the root API candidates found in the first examination to identify which of the root API candidates is actually a root API. Once the root API has been located, it is executed in a computer environment, and its dependents are detected. Once all the necessary API files have been located, they are packaged and automatically published.

Abstract: A mocking service allows a mocking instance of an API specification to receive behavior parameters with requests for resources of the API specification. The mocking service may digest these parameters and generate a response according to the parameters and using the instance of the API specification. The dynamic responses allow a service to be configured for interacting with an API corresponding to the API specification and for interacting with different response scenarios of the API. The parameters may define response behaviors such as a fixed time until a response is received, a variable time until a response is received, error rate, error codes, validations, etc. In some cases, based on a behavior parameter indicating a request for random data for a requested resource, the mock implementation of the API may generate and return random data according to variables defined in the API specification.

Abstract: A system may include a mocking server and one or more tenants served by the mocking server. A tenant may test an application programming interface (API) by creating a mock implementation of the API using a mocking service provided by the mocking server. The mocking server may generate a mock implementation of the API based on an API specification and expose an endpoint of the mock implementation for the user to perform testing. The user may provide an identifier for an API specification to the mocking server. The mocking server may retrieve the API specification from a source, parse the API specification in memory to create a mock model of the API, and generate a mock implementation for the API from the mock model. The mocking server includes an authentication mechanism to ensure that users accessing the API specification or running a mock implementation of the API are authorized.

Abstract: A system may include a mocking server and one or more tenants served by the mocking server. A tenant may test an application programming interface (API) using a mocking service. For example, the mocking server may run a mock implementation of an API based on an API specification, and the server may expose an endpoint of the mock implementation for API testing. In some cases, the API specification may use an additional service. The mocking server may need an implementation for this additional service in order to test the API. For improved efficiency and reliability of the mocking service, the mocking server may store pre-configured mock implementations for various service or complementary APIs, which can be publicly accessed and shared across multiple different tenants. The pre-configured mock implementations may enable a user to test an API without providing a mock implementation for each additional service indicated in the API specification.

Abstract: A mocking service generates a mock implementation of an API based on a API specification. Request and response behavior of the mock implementation of the API may be controlled by a separate API behavior file. The API behavior file may be parsed by the mocking service to generate behavior logic. When an API request is transmitted to the mock implementation of the API, the behavior logic is invoked and may control execution of the mock implementation of the API and the details of a generated response. Behaviors defined in the API behavior file may be global or resource specific and may include, for example, time delays, error rates, error codes, conditions, response overrides, etc.

Abstract: A system may include a mocking server and one or more tenants served by the mocking server. A tenant may test an application programming interface (API) by creating a mock implementation of the API using a mocking service provided by the mocking server. The mocking server may generate a mock implementation of the API based on an API specification and expose an endpoint of the mock implementation for the user to perform testing. The user may provide an identifier for an API specification to the mocking server. The mocking server may retrieve the API specification from a source, parse the API specification in memory to create a mock model of the API, and generate a mock implementation for the API from the mock model. The mocking server includes an authentication mechanism to ensure that users accessing the API specification or running a mock implementation of the API are authorized.

Abstract: A system may include a mocking server and one or more tenants served by the mocking server. A tenant may test an application programming interface (API) using a mocking service. For example, the mocking server may run a mock implementation of an API based on an API specification, and the server may expose an endpoint of the mock implementation for API testing. In some cases, the API specification may use an additional service. The mocking server may need an implementation for this additional service in order to test the API. For improved efficiency and reliability of the mocking service, the mocking server may store pre-configured mock implementations for various service or complementary APIs, which can be publicly accessed and shared across multiple different tenants. The pre-configured mock implementations may enable a user to test an API without providing a mock implementation for each additional service indicated in the API specification.

Abstract: A mocking service generates a mock implementation of an API based on a API specification. Request and response behavior of the mock implementation of the API may be controlled by a separate API behavior file. The API behavior file may be parsed by the mocking service to generate behavior logic. When an API request is transmitted to the mock implementation of the API, the behavior logic is invoked and may control execution of the mock implementation of the API and the details of a generated response. Behaviors defined in the API behavior file may be global or resource specific and may include, for example, time delays, error rates, error codes, conditions, response overrides, etc.

Abstract: A mocking service allows a mocking instance of an API specification to receive behavior parameters with requests for resources of the API specification. The mocking service may digest these parameters and generate a response according to the parameters and using the instance of the API specification. The dynamic responses allow a service to be configured for interacting with an API corresponding to the API specification and for interacting with different response scenarios of the API. The parameters may define response behaviors such as a fixed time until a response is received, a variable time until a response is received, error rate, error codes, validations, etc. In some cases, based on a behavior parameter indicating a request for random data for a requested resource, the mock implementation of the API may generate and return random data according to variables defined in the API specification.