Methods and systems for configuring application programming interface at different operational levels

Abstract

Methods and server systems for configuring Application Programming Interface (API) at different operational levels are described herein. The method performed by a server system includes receiving multiple API config files for the different operational levels. Herein, each API config file for an operational level includes a user selection of a service provider platform from among multiple service provider platforms for facilitating an API service. The method further includes assigning multiple interface worker entities to the operational levels based on the multiple API config files. The method includes configuring, by the multiple interface worker entities, multiple provider-specific API config files for the multiple service provider platforms from the multiple API config files based on a predefined design ruleset. The method includes implementing, by multiple interface worker entities, the multiple provider-specific API config files on the multiple service provider platforms based on the user selection.

Description

METHODS AND SYSTEMS FOR CONFIGURING APPLICATIONPROGRAMMING INTERFACE AT DIFFERENT OPERATIONAL LEVELSTECHNICAL FIELD

[0001] The present disclosure relates to the field of application development and, more particularly, to electronic methods and complex processing systems for configuring Application Programming Interfaces (APIs) at different operational levels in an API ecosystem.BACKGROUND

[0002] In recent times, Application Programming Interfaces (APIs) have become indispensable tools for the digital transformation of businesses. APIs serve a crucial role in the development of software applications, enabling seamless communication between different service providers, businesses, users, and so on. Therefore, for enhancing the user experience and efficiently delivering software solutions to users, businesses rely heavily on APIs. Due to the sheer number of APIs and the extensive use of APIs that are required for delivering software applications, API management has become quite important. Here, the term ‘API management’ refers to the process of designing, implementing, managing, and monitoring APIs for consumption by other services and / or applications. API management can be performed by any individual, such as a developer, API manager, API owner, or the like. As may be understood, API management is a complex task that is associated with various challenges, such as cost, efficiency, and complex governance.

[0003] Conventionally, API management is performed by developers using various tools that specialize in specific aspects of API management such as design, implementation, security, management, monitoring, and the like. However, conventional API management requires developers to use different tools for configuring the APIs at different operational levels such as service mesh level, API gateway level, and so on. Due to this fragmented approach to API management, establishing compatibility between the configurations of APIs at different operational levels becomes a complex task. Further, when APIs and / or the usage of the APIs must be scaled geographically, this fragmented API management and long geographical distance between the applications can lead to delays in deployment and debugging, high latency, poor performance, security vulnerabilities, and so on.

[0004] Thus, it is desirable to find technological solutions that allow for integrated anduniform configuration of APIs at different operational levels while being efficient in terms of cost and time, thereby reducing the complexity or efforts of developers in API management.SUMMARY

[0005] There exists a need for techniques to overcome one or more limitations stated above such as the complexity faced by developers while performing API management for APIs at different operational levels within the API ecosystem. Various embodiments of the present disclosure provide methods and systems for ensuring a reduction in the complexity faced by the developers along with efforts by providing an integrated and unified approach for configuring APIs at different operational levels. Reduction in this complexity leads to improved performance from the developers while deploying new APIs, debugging older APIs, addressing security vulnerabilities, and so on across various operational levels.

[0006] To achieve the above and other objectives of the present disclosure, in one aspect, a computer-implemented method for configuring API at different operational levels in an API ecosystem is disclosed. The computer-implemented method is performed by a server system. The method includes receiving a plurality of API config files for the plurality of operational levels. Herein, each API config file for an operational level includes a user selection of a service provider platform from among a plurality of service provider platforms for facilitating an API service. The method further includes assigning a plurality of interface worker entities to the plurality of operational levels based, at least in part, on the plurality of API config files. Furthermore, the method includes configuring, by the plurality of interface worker entities, a plurality of provider- specific API config files for the plurality of service provider platforms from the plurality of API config files based, at least in part, on a predefined design ruleset. The method includes implementing, by the plurality of interface worker entities, the plurality of provider- specific API config files on the plurality of service provider platforms based, at least in part, on the user selection.

[0007] An advantage of some embodiments is that receiving the plurality of API config files irrespective of different service platform provider platforms for their implementation at once saves time while reducing complexity for developers. Since the developer needs to merely select a particular service provider platform for each operational level while the preparation of the API config files, these embodiments provide a way for API management, i.e., service provider agnostic in nature.

[0008] Moreover, receiving the plurality of API config files having the user selectionabout the service provider platforms, allows for easy assignment of a plurality of interface worker entities to the plurality of operational levels. Further, by assigning the plurality of interface worker entities to the plurality of operational levels, the work of configuring a plurality of provider- specific API config files is automated, accelerating the API development process. Further, the implementation of the plurality of provider- specific API config files on the plurality of service provider platforms is also automated based on user selection, thereby making the API development process reliable and efficient.

[0009] In an aspect, upon implementation of the plurality of provider- specific API config files on the plurality of service provider platforms, the method includes generating a configuration control interface for facilitating an adjustment of one or more parameters defined in each of the plurality of provider- specific API config files for each operational level.

[0010] An advantage of some embodiments is that the generation of the configuration control interface facilitates adjustment of the one or more parameters for each operational level. Thus, making it easier for developers to manage application traffic across a stack i.e., from the origin (i.e., a service mesh level) to the edge (i.e., an edge computing level). Herein, the term ‘stack’ may refer to a collection of elements that are placed one above the other. The configuration control interface enables the management of traffic through a single console, thus providing an integrated and one-stop solution for traffic management.

[0011] In an aspect, the step of assigning the plurality of interface worker entities includes assigning the plurality of interface worker entities to the plurality of operational levels upon validation of the plurality of API config files based at least on the predefined design ruleset.

[0012] An advantage of some embodiments is that validating the plurality of API config files ensures that the API is correctly configured to meet the requirements of the developer and works as expected.

[0013] In an aspect, the plurality of operational levels includes a service mesh level, an API gateway level, and an edge computing level.

[0014] An advantage of some embodiments is that the plurality of operational levels covers the entire API ecosystem for seamless traffic management from the edge (i.e., the edge computing level) to the origin (i.e., the service mesh level). Another advantage of some embodiments is that the service mesh level indicates that the architecture within the application is microservice-based. This architecture is advantageous over a monolithic architecture as ithas benefits in terms of scalability, fault isolation, flexibility, resilience, faster time to market, and improved fault tolerance. Further, configuring the API at the API gateway level ensures secure communication to external consumers. Furthermore, configuring the API at the edge computing level allows for geographical scaling, and the use of the API is configured where web application firewall (WAF), bot protection, and other security measures are also optimized.

[0015] In an aspect, the step of implementing the plurality of provider- specific API config files on the plurality of service provider platforms includes generating a proxy API on a gateway service provider platform of the plurality of service provider platforms. The step further includes configuring the proxy API for facilitating an API gateway-level service for the API gateway-level based, at least in part, on a gateway provider- specific API config file of the plurality of provider- specific API config files. Further, the step includes configuring a mesh service provider platform of the plurality of service provider platforms for facilitating a meshlevel service for the service mesh level based, at least in part, on a mesh provider- specific API config file of the plurality of provider- specific API config files. Finally, the step includes configuring an edge service provider platform of the plurality of service provider platforms for facilitating an edge-level service for the edge computing level based, at least in part, on an edge provider- specific API config file of the plurality of provider- specific API config files. Herein, each of the plurality of provider- specific API config files includes one or more parameters that are defined to be interoperable between the plurality of operational levels and the plurality of service provider platforms.

[0016] An advantage of some embodiments is that generating the proxy API for the implementation of the gateway provider- specific API config file ensures the configuration of the API at the API gateway level without making any changes to the API itself. Further, configuring the mesh service provider platform at the service mesh level and the edge service provider platform at the edge computing level ensures a unified configuration of the API at each operational level. Another advantage is that one or more parameters are interoperable between the plurality of operational levels ensuring that the one or more parameters may remain compatible with each other for any change in values corresponding to any of the one or more parameters.

[0017] In an aspect, the computer-implemented method further includes determining whether the one or more parameters defined in the plurality of provider- specific API config files for the plurality of service provider platforms are interoperable between the plurality ofoperational levels based, at least in part, on a comparison of the one or more parameters between the plurality of operational levels. The method also includes upon determining that the one or more parameters are not interoperable, fine-tuning the one or more parameters for at least one of the plurality of operational levels based, at least in part, on a predefined interoperability criterion.

[0018] An advantage of some embodiments is that by determining whether the parameters are interoperable between the plurality of operational levels or not, interoperability between the corresponding one or more parameters can be achieved if it is not already available. Another advantage is that by fine-tuning the parameters based on the predefined interoperability criterion, the process for achieving interoperability is automated. As a result, the API development process is accelerated as manual detection and re-configuration of APIs to achieve interoperability is eliminated.

[0019] In an aspect, the computer- implemented method further includes integrating the plurality of service provider platforms at each of the plurality of interface worker entities based, at least in part, on the user selection.

[0020] An advantage of some embodiments is that integrating the plurality of service provider platforms at each of the plurality of interface worker entities ensures scalability. In particular, since new types of service provider platforms can easily be integrated at each working entity, scalability is improved.

[0021] In an aspect, each interface worker entity is configured to provision a plurality of service provider platform- specific resources corresponding to the plurality of service provider platforms integrated at the corresponding interface worker entity, required for the unified API configuration.

[0022] An advantage of some embodiments is by making the plurality of service provider platform- specific resources available at the interface worker entity for the unified API configuration, the configuration of the plurality of provider- specific API config files is simplified.

[0023] In an aspect, the computer- implemented method further includes facilitating the preparation of the plurality of API config files for the plurality of operational levels based, at least in part, on predefined policies and rules, the plurality of API config files being service provider- agno Stic .

[0024] An advantage of some embodiments is that facilitating the preparation of theplurality of API config files for the plurality of operational levels that are service provideragnostic, allows developers to effortlessly configure the API at each operational level as per their requirements.

[0025] As per another embodiment of the present disclosure, a server system is disclosed. The server system includes a communication interface and a memory including executable instructions. The server system also includes a processor communicably coupled to the memory. The processor is configured to execute the instructions to cause the server system, at least in part, to receive a plurality of API config files for the plurality of operational levels, each API config file for an operational level comprising a user selection of a service provider platform from among a plurality of service provider platforms for facilitating an API service. The server system is further caused to assign a plurality of interface worker entities to the plurality of operational levels based, at least in part, on the plurality of API config files. The server system is then caused to configure, by the plurality of interface worker entities, a plurality of provider- specific API config files for the plurality of service provider platforms from the plurality of API config files based, at least in part, on a predefined design ruleset. Lastly, the server system is caused to implement, by a plurality of interface worker entities, the plurality of provider- specific API config files on the plurality of service provider platforms based, at least in part, on the user selection.

[0026] As per yet another embodiment of the present disclosure, a non-transitory computer-readable storage medium is disclosed. The non-transitory computer-readable storage medium includes computer-executable instructions that, when executed by at least a processor of a server system, cause the server system to perform a method. The method includes receiving a plurality of API config files for the plurality of operational levels. Herein, each API config file for an operational level includes a user selection of a service provider platform from among a plurality of service provider platforms for facilitating an API service. The method further includes assigning a plurality of interface worker entities to the plurality of operational levels based, at least in part, on the plurality of API config files. Furthermore, the method includes configuring, by the plurality of interface worker entities, a plurality of providerspecific API config files for the plurality of service provider platforms from the plurality of API config files based, at least in part, on a predefined design ruleset. The method includes implementing, by a plurality of interface worker entities, the plurality of provider- specific API config files on the plurality of service provider platforms based, at least in part, on the user selection.

[0027] The foregoing summary is illustrative only and is not intended to be in any way limiting. In addition to the illustrative aspects, embodiments, and features described above, further aspects, embodiments, and features will become apparent by reference to the drawings and the following detailed description.BRIEF DESCRIPTION OF FIGURES

[0028] For a more complete understanding of example embodiments of the present technology, reference is now made to the following descriptions taken in connection with the accompanying drawings in which:

[0029] FIG. 1 is an example representation of a unified Application Programming Interface (API) management environment, in accordance with various embodiments of the present disclosure;

[0030] FIG. 2 illustrates a simplified block diagram of a server system, in accordance with an embodiment of the present disclosure;

[0031] FIG. 3 illustrates a schematic representation indicating a process flow of configuration of an API in an API ecosystem, in accordance with an embodiment of the present disclosure;

[0032] FIG. 4 illustrates a schematic representation of a high-level system architecture for configuring API at different operational levels in an API ecosystem, in accordance with an embodiment of the present disclosure; and

[0033] FIG. 5 illustrates a flow diagram of a method of operating the server system for configuring API at different operational levels in an API ecosystem, in accordance with an embodiment of the present disclosure.

[0034] The drawings referred to in this description are not to be understood as being drawn to scale except if specifically noted, and such drawings are only exemplary in nature.DETAILED DESCRIPTION

[0035] In the following description, for purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding of the present disclosure. It will be apparent, however, to one skilled in the art that the present disclosure can be practiced without these specific details. Descriptions of well-known components and processing techniques are omitted to not obscure the embodiments herein unnecessarily. The examples used herein are intended merely to facilitate an understanding of ways in which theembodiments herein may be practiced and to further enable those of skill in the art to practice the embodiments herein. Accordingly, the examples should not be construed as limiting the scope of the embodiments herein.

[0036] References in this specification to “one embodiment” or “an embodiment” means that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment of the present disclosure. The appearances of the phrase “in an embodiment” in various places in the specification are not necessarily all referring to the same embodiment, nor are separate or alternative embodiments mutually exclusive of other embodiments. Moreover, various features are described which may be exhibited by some embodiments and not by others. Similarly, various requirements are described which may be requirements for some embodiments but not for other embodiments.

[0037] Moreover, although the following description contains many specifics for the purposes of illustration, anyone skilled in the art will appreciate that many variations and / or alterations to said details are within the scope of the present disclosure. Similarly, although many of the features of the present disclosure are described in terms of each other, or in conjunction with each other, one skilled in the art will appreciate that many of these features can be provided independently of other features. Accordingly, this description of the present disclosure is set forth without any loss of generality to, and without imposing limitations upon, the present disclosure.

[0038] Conditional language such as, among others, “can”, “could”, “might”, or “may”, unless specifically stated otherwise, are otherwise understood within the context as used in general to convey that certain embodiments include, while other embodiments do not include, certain features, elements and / or steps. Thus, such conditional language is not generally intended to imply that features, elements, and / or steps are in any way required for one or more embodiments or that one or more embodiments necessarily include logic for deciding, with or without user input or prompting, whether these features, elements and / or steps are included or are to be performed in any particular embodiment.

[0039] Disjunctive language such as the phrase “at least one of X, Y, or Z” unless specifically stated otherwise, is otherwise understood with the context as used in general to present that an item, term, etc., may be either X, Y, or Z, or any combination thereof (e.g., X, Y, and / or Z). Thus, such disjunctive language is not generally intended to, and should not, imply that certain embodiments require at least one of X, at least one of Y, or at least one of Zto each be present.

[0040] Unless otherwise explicitly stated, articles such as “a” or “an” should generally be interpreted to include one or more described items. Accordingly, phrases such as “a server system configured to” are intended to include one or more recited server systems / processors. Such one or more recited devices can also be collectively configured to carry out the stated recitations. For example, “a processor configured to carry out recitations A, B, and C” can include a first processor configured to carry out recitation A working in conjunction with a second processor configured to carry out recitations B and C. The same holds true for the use of definite articles used to introduce embodiment recitations. In addition, even if a specific number of an introduced embodiment recitation is explicitly recited, those skilled in the art will recognize that such recitation should typically be interpreted to mean at least the recited number (e.g., the bare recitation of “two recitations” without other modifiers, typically means at least two recitations or two or more recitations).

[0041] It will be understood by those within the art that, in general, terms used herein, are generally intended as “open” terms (e.g., the term “including” or “comprising” should be interpreted as “including / comprising but not limited to,” the term “having” should be interpreted as “having at least,” the term “includes” or “comprises” should be interpreted as “includes / comprises but is not limited to,” etc.).

[0042] For expository purposes, the term “Application Programming Interface (API)” refers to a set of rules or protocols that are intended to be used as an interface by different software components or applications to communicate with each other. API defines how different software components should interact, what data can be accessed, and what operations can be performed between different software components. In various examples, APIs can be used to facilitate communication between different software components present within the same or different website (web) applications, mobile applications, operating systems, libraries, frameworks, and the like.

[0043] The term ‘API configuration’, ‘API management’, ‘API lifecycle configuration’, or ‘API lifecycle management’ refer to a process of designing, implementing, securing, managing, monitoring, and publishing APIs for consumption or use by other services and applications.

[0044] APIs, being the entities that control or command the interaction between different software applications or various components within software applications, must beconfigured accordingly. For instance, an API has to be configured for communication or exchange of information between services in a microservice architecture (e.g., service mesh) of an application. In another instance, an API can be configured for communication between two software applications (e.g., API gateway). In yet another instance, an API can be configured for an edge computing system (e.g., edge caching) for geographically scaling its use, as well. Conventionally, a developer utilizes different existing tools (e.g., service provider platforms) for API configuration at different operational levels, such as a service mesh level, an API gateway level, and an edge computing level separately. Examples of existing tools for management of service mesh include Istio®, Kuma®, Kong®, etc. Further, examples of existing tools for the management of API gateway include Apigee®, Amazon API Gateway®, Azure API management®, etc. Furthermore, examples of existing products for API management at the edge computing level include Akami®, AWS CloudFront®, etc.

[0045] As may be understood, the designing process being the very first step in the configuration of the API includes enforcing guidelines, standards, and best practices while designing the API. Examples of the designing tools include SwaggerHub®, Postman®, OpenAPI®, etc. More specifically, it involves API documentation based on the design guidelines using the existing design tools. Herein, it should be noted that these tools may or may not be used in further processes of API management. Once the design is ready, the next step is to create the API by also considering the security aspect, which involves choosing a preferred API architecture, audience scope, and protocols. API types based on architecture include monolithic APIs, microservice APIs, composite APIs, and unified APIs. API types based on audience scope include public APIs, private / internal APIs, and partner APIs. API types based on protocols include Representational State Transfer (REST or RESTful) APIs, Simple Object Access Protocol (SOAP) APIs, Remote Procedure Call (RPC) APIs, GraphQL APIs, and the like.

[0046] For configuring the API through such tools, developers have to first configure the API gateway. Then, they have to configure the service mesh such that it is compatible with the API gateway for smooth operation of the API. This is a complicated process that requires experienced developers to spend a lot of time to ensure compatibility. Moreover, in some instances, a service mesh management product from one provider may not be compatible with an API gateway management product from a different provider. Thus, this service providerspecific approach limits the freedom of developers during the API development process.

[0047] Although there exist solutions that facilitate the developer to access thedifferent existing tools on a single platform. However, as may be understood, having mere access to such platforms may not be very advantageous. Since the developer still has to manually configure the API by visiting these different platforms as per a rule set for that particular platform. In addition, configuring the API for compatibility between different operational levels is difficult due to a lack of cross -platform (or tool) operational compatibility.

[0048] Moving forward, upon configuration, the API has to be tested, fine-tuned, and deployed in a development environment. This introduces additional difficulties which have to be addressed using additional tools. Further, as the consumer base of an application grows geographically, the conventional tools make it difficult to scale the consumers for existing APIs. This is because the configuration has to be updated manually by developers across various tools for different operational levels and the increased distance that the API requests and responses have to travel for distant consumers. Further, this complexity also increases the latency of API responses and reduces the performance and security of the API while making the API vulnerable as well. As a result, the concept of edge computing may have to be adapted. Thus, products, such as Akami®, AWS CloudFront®, etc., may be used by the developer, separately for geographically scaling the consumption of the APIs. However, for the developer to configure the API at each level starting from the origin (i.e., service mesh) to the edge (i.e., edge computing), using different available tools by accessing different platforms with appropriate compatibility is time-consuming and a complex task.

[0049] To that end, various embodiments of the present disclosure aim to solve the above-mentioned technical problems by providing an approach for seamlessly configuring the API for different operational levels. This configuration is performed for different service provider platforms through an integrated and unified solution. The approach of the present disclosure aims to simplify the task of the developer in configuring the API for different operational levels. This task is simplified by unifying all the service provider platforms into a single pane. In other words, the application traffic across the stack, i.e., from the origin (service mesh) to the edge can be managed smoothly, resulting in effective API management.

[0050] FIG. 1 is an example representation of a unified Application Programming Interface (API) management environment 100, in accordance with various embodiments of the present disclosure. The environment 100 includes a server system 102, a plurality of users 104 A, 104B, and 104C (hereafter collectively referred to as ‘users 104’), a plurality of service provider platforms 106A, 106B, and 106C (hereafter collectively referred to as ‘service provider platforms 106’), each coupled to, and in communication with (and / or with access to)a network 108. In a non-limiting example, the server system 102 may be configured to perform one or more operations, such as, but not limited to, facilitating preparation of API configuration (config) files, and the like. In a non-limiting example, the operational levels may include a service mesh level, an API gateway level, and an edge computing level.

[0051] In an embodiment, the users 104 may be, but are not limited to, individuals, institutions, organizations, Artificial Intelligence-based bots, software applications, and the like. In a non-limiting example, the user 104A may be an individual who is responsible for developing and managing an API. For instance, the user 104A can be a developer, an API manager, a gatekeeper, or the like. Further, the user 104B may be an API consumer in some instances as well. For instance, the user 104B can be a chatbot, a software application, or the like.

[0052] Similarly, the service provider platforms 106 may be platforms that are developed by the users 104 that provide services for the implementation of different processes associated with API management at a particular operational level. The various processes associated with API management may include, but are not limited to, designing, implementing, securing, managing, monitoring, publishing, or the like. In one embodiment, the service provider platforms 106 may be developed by other individuals, organizations, institutions, or the like.

[0053] The network 108 may include, without limitation, a Light Fidelity (Li-Fi) network, a Local Area Network (LAN), a Wide Area Network (WAN), a Metropolitan Area Network (MAN), a satellite network, the Internet, a fiber optic network, a coaxial cable network, an Infrared (IR) network, a Radio Frequency (RF) network, a virtual network, and / or another suitable public and / or private network capable of supporting communication among two or more of the parts or components illustrated in FIG. 1, or any combination thereof.

[0054] Various entities in the environment 100 may connect to the network 108 in accordance with various wired and wireless communication protocols, such as Transmission Control Protocol / Intemet Protocol (TCP / IP), User Datagram Protocol (UDP), 2nd Generation (2G), 3rd Generation (3G), 4th Generation (4G), 5th Generation (5G) communication protocols, Long Term Evolution (LTE) communication protocols, future communication protocols or any combination thereof. For example, the network 108 may include multiple different networks, such as a private network made accessible by the server system 102 and a public network (e.g., the Internet, etc.) through which the server system 102, the users 104,and the service provider platforms 106 may communicate.

[0055] In some instances, each user of the users 104 is associated with an electronic device, such as a desktop computer and mobile device as shown in the environment 100. In one embodiment, a user such as the user 104A may use any electronic device that may be configured to facilitate the user 104A in interacting with the unified API configuration at different operational levels in the API ecosystem. In another embodiment, a user such as the user 104B may use any electronic device for the consumption or use of the API.

[0056] In one embodiment, each of the service provider platforms 106 may be installed on one or more electronic devices such as, but not limited to, a mobile device (e.g., a mobile phone, a smartphone, a tablet, etc.), a smart television, a laptop, a desktop, and the like. These service provider platforms 106 may be used for configuring the API at different operational levels. Herein, the electronic device may be associated with the user 104A. In another embodiment, the service provider platforms 106 may be accessed by the user 104A through various web or cloud-implemented services such as a website or web app. The user 104A may access these service provider platforms 106 through a Uniform Resource Locator (URL) link associated with the corresponding service provider platforms 106.

[0057] As described earlier, the user 104A (e.g., the developer) has to configure the API at different operational levels for different service provider platforms 106 that may be used during the API development process. This is a time-consuming and complicated process that requires a lot of energy from a developer or team of developers (hereinafter, the terms ‘user 104A’ and ‘developer’ are used interchangeably for the sake of simplicity of the explanation. As described earlier, since each service provider platform has a specific predefined ruleset for developing API through them, any API configuration done using such platforms has to be performed adhering to their rulesets. In addition, every service provider platform has a separate login and requires a unique login credential of the developer for its usage which further adds friction to the development of the API at different operational levels. It is understood that API configurations are prepared and stored by the developers in the form of a file.

[0058] Also, it should be noted that, in one scenario, an API config file prepared using a service provider platform provided by a first service provider for a particular operational level may not be compatible with an API config file prepared using a service provider platform provided by a second service provider for the operational level. In another scenario, if the sameservice provider provides a service provider platform for a first operational level and another service provider platform for a second operation level, then API config files prepared using such platforms may be compatible with each other. Thus, it may be understood that choosing service provider platforms that are compatible with each other for different operational levels requires effort and energy to be put in by the developer, making the process time-consuming. Also, preparing an API config file at one operational level that is compatible with an API config file at another operational level irrespective of the service provider platforms used for preparing the config files is time-consuming.

[0059] To overcome these problems and other problems, an approach that integrates all the service provider platforms on a single panel and facilitates the developer to prepare the API config files for each operational level is required. Also, the preparation of the API config files should be irrespective of the service provider platform that may be used for the implementation of the corresponding API config files. To that end, to address the above- mentioned limitation, the present disclosure describes that the server system 102 may provide a single control panel that facilitates the developer to choose parameters for the preparation of the API config files for each operational level.

[0060] In one embodiment, the environment 100 may further include a repository 110 coupled with the server system 102. In an example, the server system 102 coupled with the repository 110 is embodied within a central server (not shown) associated with the employer of the users 104. However, in other examples, the server system 102 can be a standalone component (acting as a hub) connected to the central server. The repository 110 may be incorporated in the server system 102 or maybe an individual entity connected to the server system 102 or maybe a repository stored in cloud storage. In one embodiment, the repository 110 may be associated with one or more databases, each database storing simple, structured, and relational data. Thus, it may be understood that the repository 110 may be configured to store data that is complex, unstructured, and non-relational data. In addition, the repository 110 can store data for multiple purposes, and may be considered as a large storage unit that can store various project files and resources.

[0061] In a non-limiting example, the repository 110 can store a plurality of API config files prepared by the user 104A, user selection data, a predefined design ruleset, and the like. The repository 110 can also store other necessary machine instructions required for implementing the various functionalities of the server system 102 such as firmware data, operating system, and the like. It is noted that details associated with data stored in therepository 110 have been explained in detail later in the present disclosure. In addition, the repository 110 provides a storage location for data and / or metadata obtained from various operations performed by the server system 102.

[0062] In an embodiment, the server system 102 facilitates the preparation of a plurality of API config files for a plurality of operational levels based, at least in part, on predefined policies and rules. Herein, the predefined policies and rules may be specific to a specific operational level. Accordingly, the API config files may have to be prepared by the developer (e.g., the user 104A). In a non-limiting implementation, the server system 102 may be accessible to the developer in the form of a website, a website application, a mobile application, a developer portal, or the like on an electronic device associated with the developer. In some instances, the developer portal may display a plurality of options on a user interface for the developer. The developer may select an option for performing a particular operation during the API configuration. In various examples, the plurality of options may be in the form of levers, buttons, blank spaces to be filled with values or characters, or the like. The developer can provide values to one or more parameters required to be maintained for a particular operational level by selecting from the options displayed on the developer portal. Herein, the values may have to suit for optimized operation of the API at the corresponding operational level which is defined in the predefined policies and rules. Upon selection, a plurality of API config files may be generated for each operational level and stored in the repository 110. Herein, it should be noted that the API config files can be accessed in the future for further processing and configuration of the API at each operational level. Also, as the plurality of API config files are service provider-agnostic, the files may have configurations that are generic and not specific to any service provider platform. In a non-limiting implementation, the plurality of API config files may include at least a gateway- specific API config file, a mesh-specific API config file, an edge-specific API config file, and the like.

[0063] The server system 102 may be configured to receive the plurality of API config files for the plurality of operational levels. In a non-limiting example, it is to be noted that, along with one or more parameters, the developer may have the freedom to select a service provider platform (e.g., the service provider platform 106A) for implementation of the API configuration on each operational level. Thus, each API config file for an operational level may include a user selection of a service provider platform (e.g., the service provider platform 106A) from among a plurality of service provider platforms (e.g., the service provider platforms 106) for facilitating an API service. This user selection of the service providerplatform may be utilized for the implementation of the API service for the corresponding operational levels.

[0064] Further, the server system 102 may be configured to assign a plurality of interface worker entities to the plurality of operational levels based, at least in part, on the plurality of API config files. In various non-limiting examples, an interface worker entity may include an individual, an organization, a set of instructions, a software application, a chatbot, or the like that is specialized and / or configured to provision a plurality of service provider platform- specific resources corresponding to the service provider platforms 106 integrated at the corresponding interface worker entity, required for the unified API configuration.

[0065] Further, the server system 102 may be configured to facilitate the interface worker entities to configure a plurality of provider- specific API config files for the service provider platforms 106 from the plurality of API config files based, at least in part, on the predefined design ruleset. In one embodiment, the server system 102 may facilitate this configuration based on a user selection received from the user 104A. Herein, the configuration may refer to the translation of received configurations to the service provider- specific configurations or the particular operational level.

[0066] In some embodiments, the assignment of the interface worker entities to the operational levels enables the server system 102 to integrate a plurality of service provider platforms (e.g., the service provider platforms 106) at the corresponding interface worker entity. In one embodiment, the integration may be dependent on the user selection. Moreover, the integration of the service provider platforms 106 at the interface worker entities includes integrating Application Programming Interfaces (APIs) or Software development kit (SDK) corresponding to the service provider platforms 106 in the corresponding interface worker entity. The integration facilitates communication between the interface worker entity and the integrated service provider platforms 106 to provision or update the service provider platformspecific resources.

[0067] As may be understood that, once the plurality of provider- specific API config files is obtained for each operational level, there is a possibility that the one or more parameters in the files are not interoperable between different operational levels. Thus, in some embodiments, the server system 102 may be configured to determine whether the one or more parameters defined in the plurality of provider- specific API config files for the service provider platforms are interoperable between the plurality of operational levels based, at least in part,on a comparison of the one or more parameters between the plurality of operational levels.

[0068] In one embodiment, upon determining that the one or more parameters are not interoperable, the server system 102 may be configured to fine-tune the one or more parameters for at least one of the plurality of operational levels based, at least in part, on a predefined interoperability criterion. In another embodiment, upon determining that the one or more parameters are interoperable, the server system 102 may be signaled to proceed with the implementation step.

[0069] Further, the plurality of provider- specific API config files can be implemented on respective service provider platforms. Thus, the server system 102 may be configured to facilitate the interface worker entities to implement the plurality of provider- specific API config files on the service provider platforms based, at least in part, on the user selection.

[0070] In one embodiment, upon implementation, the server system 102 may be configured to generate a configuration control interface for facilitating an adjustment of one or more parameters defined in each of the plurality of provider- specific API config files for each operational level. Herein, the server system 102 facilitates the developer to adjust one or more parameters for each operational level. A detailed explanation of various operations required for unified API configuration at different operational levels by the server system 102 is provided later in reference to FIG. 2 and FIG. 3.

[0071] Although in FIG. 1, the server system 102 is shown to be incorporated within the environment 100, in some embodiments, the server system 102 may be external to and in communication with the environment 100, for example, via the network 108. In some examples, the server system 102 may be implemented in third-party external servers to perform the various operations described herein.

[0072] The number and arrangement of systems, devices, and / or networks shown in FIG. 1 are provided as an example. There may be additional systems, devices, and / or networks; fewer systems, devices, and / or networks; different systems, devices, and / or networks; and / or differently arranged systems, devices, and / or networks than those shown in FIG. 1. Furthermore, two or more systems or devices shown in FIG. 1 may be implemented within a single system or device, or a single system or device is shown in FIG. 1 may be implemented as multiple, distributed systems or devices. In addition, the server system 102 should be understood to be embodied in at least one computing device in communication with the network 108, which may be specifically configured, via executable instructions, to performsteps as described herein, and / or embodied in at least one non-transitory computer-readable media.

[0073] FIG. 2 illustrates a simplified block diagram of a server system 200, in accordance with an embodiment of the present disclosure. It is noted that the server system 200 may be similar to the server system 102 of FIG. 1. In one embodiment, the server system 200 is a part of the internal server operated by an organization employing the user such as the user 104A (otherwise also referred to as a developer). In some embodiments, the server system 200 is embodied as a cloud-based and / or Software as a Service (SaaS) based architecture.

[0074] The server system 200 includes a computer system 202 and a repository 204. It is noted that the repository 204 is identical to the repository 110 of FIG. 1. The computer system 202 includes at least one processor 206 (herein, referred to interchangeably as ‘processor 206’) for executing instructions, a memory 208, a communication interface 210, a user interface 212, and a storage interface 214 that communicates with each other via a bus 216.

[0075] In some embodiments, the repository 204 is integrated into the computer system 202. For example, the computer system 202 may include one or more hard disk drives like repository 204. The user interface 212 is an interface, such as a Human Machine Interface (HMI) or a software application that allows users such as an administrator to interact with and control the server system 200 or one or more parameters associated with the server system 200. It may be noted that the user interface 212 may be composed of several components that vary based on the complexity and purpose of the application. Examples of components of the user interface 212 may include visual elements, controls, navigation, accessibility features, etc.

[0076] The storage interface 214 is any component capable of providing the processor 206 with access to the repository 204. The storage interface 214 may include, for example, an Advanced Technology Attachment (ATA) adapter, a Serial ATA (SATA) adapter, a Small Computer System Interface (SCSI) adapter, a RAID controller, a SAN adapter, a network adapter, and / or any component providing the processor 206 with access to the repository 204.

[0077] In one non-limiting example, the repository 204 is configured to store a plurality of API config files (see, API config files 218) prepared by the user 104A, user selection data 220, a predefined design ruleset 222, a plurality of provider- specific API config files 224, and the like. In a non-limiting example, the API config files 218 may include a gateway- specific API config file, a mesh-specific API config file, an edge-specific API configfile, and the like. In various non-limiting examples, the gateway-specific API config file may include configurations, such as, but not limited to, spike arrest, quota, routing rules, and the like. It may be understood that the gateway-specific API config file may be one of the API config files 218 that may be used for API configuration at the API gateway level. The meshspecific API config file may include configurations, such as, but not limited to, routing, retries, a timeout value, and the like. It may be understood that the mesh-specific API config file may be one of the API config files 218 that may be used for API configuration at the service mesh level. Further, the edge-specific API config file may include configurations, such as, but not limited to, edge caching, web application firewall (WAF) protection rules, Distributed Denial of Service (DDoS) protection rules, and the like. Collectively, it can be stated that the one or more parameters may include, but are not limited to, spike arrest, quota, routing rules, retries, timeout value, edge caching, WAF protection rules, DDoS protection rules, valid paths, bot traffic protection, and the like.

[0078] In a non-limiting example, the API config files 218 may be stored in the repository 204 in a predefined file format, such as Extensible Markup Language (XML) file format, JavaScript Object Notation (JSON) file format, Yet Another Markup Language (YAML) file format, or the like. Herein, each file format may be generated using programming languages, such as XML, JSON, YAML, or the like, respectively. Herein, each of these languages is well known to a person skilled in art, and hence the same is not elaborated here for the sake of brevity. In various non-limiting examples, the API config files may include ‘proxy-config.yml’, ‘mesh-policies. yml’, ‘edge-policies. yml’, and the like for API gateway configuration, service mesh configuration, edge configuration, and the like, respectively.

[0079] Further, in one embodiment, the user selection data 220 may include information related to the user selections made by the developer (e.g., the user 104A) during the preparation of the API config files 218. The user selections may correspond to the options selected by the developer for the one or more parameters that are part of the API configuration operation. The user selections also include the user selection of the service provider platforms 106 for each operational level for facilitating the API services.

[0080] In one embodiment, the predefined design ruleset 222 can include an ‘Open API specification’. As may be understood, the ‘Open API specification’ refers to a specification for writing a public API, with guidelines for details, such as endpoint naming conventions, data formats, error messaging, and the like. Further, a private API can also adhere to standards set by the ‘Open API specification’. Thus, the ‘Open API specification’ is used asthe predefined design ruleset 222 for validating the API config files for API configuration at each operational level. It should be noted that, the predefined design ruleset 222 may have to be defined such that not only the predefined guidelines, but also API documentation, API security, API analytics, and the like are appropriate for API configuration.

[0081] In some embodiments, the repository 204 may also store historical information related to the users 104. In an embodiment, the historical information related to the users 104 may include personal details, such as name, contact number, email Identifier (ID), etc., login credentials for different service provider platforms, historical APIs configured, historical APIs accessed, unique keys, and the like.

[0082] In some other embodiments, the repository 204 may also store historical information related to the API configuration, such as earlier data rates, timeouts, quotes, preferred databases, preferred data storage format, predefined policies and rules set by the governments in different jurisdictions, API documentations, API security-related data, and the like.

[0083] The processor 206 includes suitable logic, circuitry, and / or interfaces to execute operations for receiving the API config files, assigning interface worker entities to the operational levels, configuring service provider- specific API config files, implementing the provider- specific API config files on the service provider platforms, and the like. Examples of the processor 206 include, but are not limited to, an Application-Specific Integrated Circuit (ASIC) processor, a Reduced Instruction Set Computing (RISC) processor, a Graphical Processing Unit (GPU), a Complex Instruction Set Computing (CISC) processor, a Field- Programmable Gate Array (FPGA), and the like.

[0084] The memory 208 includes suitable logic, circuitry, and / or interfaces to store a set of computer-readable instructions for performing the various operations described herein. Examples of the memory 208 include a random-access memory (RAM), a read-only memory (ROM), a removable storage drive, a hard disk drive (HDD), and the like. It will be apparent to a person skilled in the art that the scope of the disclosure is not limited to realizing the memory 208 in the server system 200, as described herein. In another embodiment, the memory 208 may be realized in the form of a database server or a cloud storage working in conjunction with the server system 200, without departing from the scope of the present disclosure.

[0085] The processor 206 is operatively coupled to the communication interface 210, such that the processor 206 is capable of communicating with a remote device (i.e., to / from aremote device 226) such as third-party servers or with the users 104 and the service provider platforms 106, or communicating with any entity connected to the network 108 (as shown in FIG. 1).

[0086] It is noted that the server system 200 as illustrated and hereinafter described is merely illustrative of an apparatus that could benefit from embodiments of the present disclosure and, therefore, should not be taken to limit the scope of the present disclosure. It is noted that the server system 200 may include fewer or more components than those depicted in FIG. 2.

[0087] In one implementation, the processor 206 includes an input / output module 228, a validation module 230, an integration module 232, an interoperability management module 234, and a configuration module 236. It should be noted that components, described herein, such as the input / output module 228, the validation module 230, the integration module 232, the interoperability management module 234, and the configuration module 236 can be configured in a variety of ways, including electronic circuitries, digital arithmetic, and logic blocks, and memory systems in combination with software, firmware, and embedded technologies. In various non-limiting examples, the input / output module 228, the validation module 230, the integration module 232, the interoperability management module 234, and the configuration module 236 may be communicatively coupled with each other and can transfer data between the modules.

[0088] In an embodiment, the input / output module 228 includes suitable logic and / or interfaces for receiving the API config files 218 for the plurality of operational levels. Herein, the API config files 218 also include the user selection of the service provider platforms 106 for facilitating the API service. In a non-limiting implementation, the plurality of API config files may include a gateway-specific API config file, a mesh-specific API config file, an edgespecific API config file, and the like.

[0089] As may be understood, the preparation of the gateway- specific API config file requires information related to the configuration of a proxy in the API gateway. Thus, the developer creates a new gateway-specific API config file which will define the settings and behavior of the proxy. This configuration will serve as a crucial link between the external API requests and the internal systems, allowing for control, security, and routing. It should be noted that the new gateway-specific API config file may be prepared by referring to a sample proxy config file that may be pre-stored in the repository 204. Similarly, other API config files arealso prepared for the rest of the operational levels. Upon receiving the API config files 218, it has to be validated. Thus, the API config files 218 may be transferred to the validation module 230.

[0090] In one embodiment, the validation module 230 includes suitable logic and / or interfaces for validating the API config files 218 based at least on the predefined design ruleset 222. Herein, the predefined design ruleset 222 may include information related to design and governance, guidelines, standards, and best practices for designing an API. In a non-limiting implementation, the predefined design ruleset may be defined by an authorized person, government authority, authorized private organization, or the like. Also, it is to be noted that, the predefined design ruleset is universal for all types of the service provider platforms 106. Herein, examples of design tools that can be used for defining the predefined design ruleset include SwaggerHub®, Postman®, OpenAPI®, etc.

[0091] For instance, if a cache configuration for an edge computing system is specified for path: ‘ / pets’, but there is no mention of ‘ / pets’ in the Open API specification. Then, the validation module 230 may consider the corresponding configuration as invalid. Similarly, if the API is meant to be the private API but there is no mention of an identity provider, such as ForgeRock® or Azure® then it’s invalid too. Upon successful validation, the API config files 218 may be transferred to the integration module 232.

[0092] In one embodiment, the integration module 232 includes suitable logic and / or interfaces for assigning a plurality of interface worker entities to the plurality of operational levels based, at least in part, on the plurality of API config files, upon successful validation. Further, in another embodiment, the integration module 232 may be configured to facilitate the interface worker entities to configure a plurality of provider- specific API config files (see, the provider- specific API config files 224) for the service provider platforms 106 from the API config files 218 based, at least in part, on the predefined design ruleset 222. As described earlier, the configuration is based on the user selection data 220 as well. For instance, for the user selection of Istio® for the service mesh level, a mesh interface worker entity of the plurality of interface worker entities may configure or prepare a service provider- specific API config file from the received API config file for Istio® based on the predefined design ruleset 222.

[0093] In another embodiment, the integration module 232 may also be configured to integrate the service provider platforms 106 at the corresponding interface worker entity. Herein, as mentioned earlier, the integration also depends on the user selection data 220. Forinstance, if the developer has selected Istio® for API management at the service mesh level, Apigee® for API management at the API gateway level, and Akami® for API management at the edge computing level. Then, the server system 102 may integrate Istio® at a mesh interface worker entity of the plurality of interface worker entities. Further, the server system 102 may integrate Apigee® at a gateway interface worker entity of the plurality of interface worker entities. Similarly, the server system 102 may integrate Akami® at an edge interface worker entity of the plurality of interface worker entities.

[0094] In one embodiment, the interoperability management module 234 includes suitable logic and / or interfaces for determining whether the one or more parameters defined in the provider- specific API config files 224 for the service provider platforms 106 are interoperable between the plurality of operational levels based, at least in part, on a comparison of the one or more parameters between the plurality of operational levels.

[0095] In another embodiment, the interoperability management module 234 may further be configured to fine-tune the one or more parameters for at least one of the plurality of operational levels based, at least in part, on a predefined interoperability criterion, when the corresponding one or more parameters are not interoperable. In an embodiment, the predefined interoperability criterion may include a set of rules that are predefined such that parameters for one operational level complement or is compatible with parameters for other operational levels in the API ecosystem. For instance, the rate at which data is received at the API gateway is about 300 bits per second (bps), whereas the rate at which the service mesh is receiving data is about 200 bps. Thus, a delay may be introduced and hence part of the data may be lost. To overcome this problem, the interoperability management module 234 fine-tunes the rate either at the API gateway level or at the service mesh level for the rates at each operational level match.

[0096] In one embodiment, the configuration module 236 includes suitable logic and / or interfaces for facilitating the interface worker entities to implement the providerspecific API config files 224 on the service provider platforms 106 based, at least in part, on the user selection. The process of implementation is explained in detail later with reference to FIG. 3.

[0097] FIG. 3 illustrates a schematic representation 300 indicating a process flow of configuration of an API in an API ecosystem, in accordance with an embodiment of the present disclosure. In a non-limiting example, an organization 302 may employ teams of users 104such as developers to develop or maintain the APIs for the digital infrastructure of their software suite. Examples of the software suite offered by the organization 302 include internal web applications, external web applications, web services, web platforms, and so on. Digital systems assist the teams in managing operations within the respective teams, ultimately taking care of multiple different tasks of the organization 302. Examples of the teams of users 104 include at least an administrative team, a technical project team, a troubleshooting team, a sales team, and so on. In an embodiment, the users 104 may use a computer system 304 associated with any member of the organization 302 to access the digital systems. Further, for cross-team communication to exchange data between the teams or between the digital systems (i.e., software applications), API (see, 306) is used.

[0098] In various instances, the API 306 can be locally stored in a repository 308 such as a local repository associated with the organization 302 or in a cloud storage. In one embodiment, the repository 308 may be substantially similar to the repository 204 of FIG. 2. In some scenarios, access to a network (e.g., the network 108) such as the internet or a private network may be required to access the API 306 (see, 310). In a specific scenario, the computer system 304 associated with a user such as the user 104A employed by the organization 302 can be used to make API calls (or requests) with applications, such as applications 312, 314, or 316 within the organization 302. Upon receiving the request, a web server associated with the API 306 at the backend may access the repository 308 to exchange the requested information between the applications 312, 314, or 316. Herein, the API 306 is configured to facilitate the applications 312-316 to communicate with each other via an API gateway 318 as shown in FIG. 3. Herein, it may be noted that the API gateway 318 is one of the products / services offered a service provider such as a provider 320 from the service provider platforms 106.

[0099] In some scenarios, one or more of the applications (e.g., application 316) can have a microservice architecture (i.e., in a distributed environment) in which the various functionalities of the application 316 are split into multiple services, such as service 316A, service 316B, and service 316C. In such scenarios, the API 306 is configured to facilitate these services 316A-316C to communicate with each other. For this configuration, a service mesh 322 is one of the existing products / services offered by another service provider such as a provider 324 from the service provider platforms 106. Further, the API 306 may also facilitate communication with external consumer applications such as consumers 326, 328, and 330.

[0100] In a scenario, suppose a distant consumer such as an application 332 locatedgeographically away from the API 306 is required to communicate with the API 306. In such a scenario, the concept of edge computing is used to avoid latency. Herein, the term ‘edge computing’ refers to a distributed computing paradigm that runs workloads at the edge i.e., closer to devices and end users. In the current scenario, the application 332 runs on a web server 334 that is located at a distant geographical location from the location of the repository 308 having the API 306. For the application 332 to be able to access the API 306 without experiencing any latency, it may be cached at an edge node that is geographically closer to the end user i.e., the web server 334 on which the application 332 is made to run. As used herein, the term ‘edge node’ refers to a computer that acts as an end-user portal for communication with other nodes in the network. For instance, the edge node such as the computer system 336 is associated with cache 338. Further, the concept of edge caching is applied at the edge node to enhance performance and avoid latency. In edge caching, an API gateway (e.g., the API gateway 318) caches responses for API calls from the application 332 in the edge node (i.e., in the cache 338 associated with the computer system 336). So that, when next time the response to an API call is made by looking up in the responses stored in the cache 338. In other words, frequently accessed data and content from the API 306 is stored in the cache 338. Herein, edge caching and other security-related parameters may be configured by a plurality of service provider platforms such as a provider 340.

[0101] It is to be noted that the organization 302 has utilized features of the server system 200 to enable the configuration of the API 306 for it to be accessible to all the operational levels such as at the API gateway 318, the service mesh 322, and the edge node (i.e., at the computer system 336 which is associated with the cache 338). Further, it may be noted that for the configuration of the API 306 for the above-mentioned operational levels, a plurality of provider- specific API config files may be obtained through the server system 200. Further, these API config files for the plurality of service provider platforms, such as the providers 320, 324, and 340 may have to be implemented. In various examples, the plurality of provider- specific API config files may include at least one of a gateway- specific API config file, a mesh-specific API config file, and an edge-specific Al config file that have to be implemented on the providers 320, 324, and 340, respectively.

[0102] In one embodiment, for the implementation of the plurality of provider- specific API config files, the configuration module 236 of the server system 200 may be configured to generate a proxy API 346 on a gateway service provider platform (i.e., the provider 320) of the plurality of service provider platforms. Herein, the term ‘proxy API’ refers to a piece ofcode that sits between a consumer (e.g., consumers 326, 328, and 330) and an API 306, providing an access point to the API 306 with additional functionality such as security, caching, or rate limiting, without requiring changes to the existing API 306.

[0103] Further, the configuration module 236 may be caused to configure the proxy API 346 for facilitating an API gateway-level service for the API gateway-level (at the API gateway 318) based, at least in part, on the gateway provider- specific API config file. The configuration module 236 may further be caused to configure a mesh service provider platform (i.e., the provider 324) of the plurality of service provider platforms for facilitating a meshlevel service for the service mesh level (at the service mesh 322) based, at least in part, on the mesh provider- specific API config file.

[0104] Furthermore, the configuration module 236 may be caused to configure an edge service provider platform (i.e., the provider 340) of the plurality of service provider platforms for facilitating an edge-level service for the edge computing level (at the edge node i.e., the computer system 336 which is associated with the cache 338) based, at least in part, on the edge provider- specific API config file. Herein, each of the plurality of provider-specific API config files may include the one or more parameters that are defined to be interoperable between the plurality of operational levels and the plurality of service provider platforms.

[0105] Upon successful implementation of the plurality of provider- specific API config files, the API 306 is now configured to accept and respond to the API calls from internal applications, internal services, external consumers as well as distant consumers.

[0106] FIG. 4 illustrates a schematic representation 400 of a high-level system architecture for configuring an API (e.g., the API 306) at different operational levels (e.g., the API gateway 318, the service mesh 322, and the edge node, i.e., at the computer system 336 which is associated with the cache 338) in an API ecosystem, in accordance with an embodiment of the present disclosure. It is noted that the high-level system architecture depicted in FIG. 4 portrays the system architecture of the server system 200. As mentioned earlier, the server system 200 may be configured to generate a configuration control interface 402 for facilitating an adjustment of one or more parameters defined in each of the plurality of provider- specific API config files for each operational level. In a specific implementation, the server system 200 may generate the configuration control interface 402 upon implementation of the plurality of provider- specific API config files on the plurality of service provider platforms, such as the providers 320, 324, and 340.

[0107] In a non-limiting implementation, the configuration control interface 402 may facilitate the user 104A to manage the values associated with the one or more parameters using GitOps pipelines for managing a few API life cycle operations. In an instance, the configuration control interface 402 can be a web user interface. Further, the configuration control interface 402 may be configured to display the plurality of interface worker entities to the user 104A. In the depicted scenario, the plurality of interface worker entities may be displayed as a gateway interface worker entity 404, a mesh interface worker entity 406, and an edge interface worker entity 408 that are arranged by the server system 200. The server system 200 may assign the gateway interface worker entity 404, the mesh interface worker entity 406, and the edge interface worker entity 408 to operational levels such as the API gateway 318, the service mesh 322, and the edge node i.e., at the computer system 336 which is associated with the cache 338, respectively.

[0108] Further, as described earlier, the server system 200 can integrate the plurality of service provider platforms at each of the plurality of interface worker entities i.e., 404-408 based, at least in part, on the user selection. As depicted in FIG. 4, the gateway interface worker entity 404 may be integrated with service provider platforms 410 and 412, the mesh interface worker entity 406 with service provider platforms 414 and 416, and the edge interface worker entity 408 with service provider platforms 418 and 420. Herein, each interface worker entity can be responsible for managing the service provider platforms at the corresponding operational level. Also, in an embodiment, new types of worker entities can be easily added to support additional service provider platforms.

[0109] In an embodiment, the step of assigning the interface worker entities to the operational levels and the step of integrating the service provider platforms at the interface worker entities can be performed using an open-source orchestration engine which is temporal. Herein, the concept of the open-source orchestration engine is well to a person skilled in the art and hence is not described here for the sake of brevity.

[0110] In one embodiment, the service provider platforms 410 or 412, the service provider platforms 414 or 416, and the service provider platforms 418 or 420 may be provided by the same service provider. In another embodiment, each of the service provider platforms 410-420 may be provided by different service providers. As may be appreciated, even with the presence of different service providers, the configuration of the API can be done efficiently upon receiving the API config files that are generic and irrespective of the service providers of the service provider platforms 410-420.

[0111] For example, during deployment of the API 306 on a deployment platform such as GitHub, once all the API config files are pushed and ready on the deployment platform, an onboarding process of the API 306 is triggered. Upon detection of the trigger, all the configurations are captured by the configuration control interface 402. In an instance, these configurations may be captured through the GitOps pipeline. Further, these configurations are validated via the operation of the server system 200. Upon successful validation, the respective interface worker entities are orchestrated to provision the resources. Each interface worker entity performs the translation operation for configuring the provider- specific API config files. Finally, the provider- specific API config files are implemented on the respective service provider platforms for each operational level by the respective interface worker entities.

[0112] FIG. 5 illustrates a flow diagram of a method of operating the server system 200 for configuring API at different operational levels in an API ecosystem, in accordance with an embodiment of the present disclosure. The method 500 depicted in the flow diagram may be executed by, for example, the server system 200. The sequence of operations of the method 500 may not be necessarily executed in the same order as they are presented. Further, one or more operations may be grouped and performed in the form of a single step, or one operation may have several sub-steps that may be performed in parallel or in a sequential manner. Operations of the method 500, and combinations of operations in the method 500 may be implemented by, for example, hardware, firmware, a processor, circuitry, and / or a different device associated with the execution of software that includes one or more computer program instructions. The plurality of operations is depicted in the process flow of the method 500. The process flow starts at operation 502.

[0113] At 502, the method 500 includes receiving a plurality of API config files for the plurality of operational levels. Each API config file for an operational level may include a user selection of a service provider platform (e.g., the service provider platform 106A) from among a plurality of service provider platforms (e.g., the service provider platforms 106) for facilitating an API service.

[0114] At 504, the method 500 includes validating the plurality of API config files based at least on a predefined design ruleset.

[0115] At 506, the method 500 includes upon successful validation, assigning a plurality of interface worker entities to the plurality of operational levels based, at least in part, on the plurality of API config files.

[0116] At 508, the method 500 includes configuring, by the plurality of interface worker entities, a plurality of provider- specific API config files for the service provider platforms 106 from the plurality of API config files based, at least in part, on a predefined design ruleset.

[0117] At 510, the method 500 includes determining whether the one or more parameters defined in the plurality of provider- specific API config files for the service provider platforms 106 are interoperable between the plurality of operational levels based, at least in part, on a comparison of the one or more parameters between the plurality of operational levels.

[0118] At 512, the method 500 includes upon determining that the one or more parameters are not interoperable, fine-tuning the one or more parameters for at least one of the plurality of operational levels based, at least in part, on a predefined interoperability criterion.

[0119] At 514, the method 500 includes implementing, by a plurality of interface worker entities, the plurality of provider- specific API config files on the service provider platforms 106 based, at least in part, on the user selection.

[0120] The disclosed method with reference to FIG. 5, or one or more operations of the server system 200 may be implemented using software including computer-executable instructions stored on one or more computer-readable media (e.g., non-transitory computer- readable media, such as one or more optical media discs, volatile memory components (e.g., DRAM or SRAM), or nonvolatile memory or storage components (e.g., hard drives or solid- state nonvolatile memory components, such as Flash memory components) and executed on a computer (e.g., any suitable computer, such as a laptop computer, netbook, Web book, tablet computing device, smartphone, or other mobile computing devices). Such software may be executed, for example, on a single local computer or in a network environment (e.g., via the Internet, a wide-area network, a local-area network, a remote web-based server, a client-server network (such as a cloud computing network), or other such networks) using one or more network computers.

[0121] Additionally, any of the intermediate or final data created and used during the implementation of the disclosed methods or systems may also be stored on one or more computer-readable media (e.g., non-transitory computer-readable media) and are considered to be within the scope of the disclosed technology. Furthermore, any of the software-based embodiments may be uploaded, downloaded, or remotely accessed through a suitable communication means. Such suitable communication means include, for example, the Internet,the World Wide Web (WWW), an intranet, software applications, cable (including fiber optic cable), magnetic communications, electromagnetic communications (including RF, microwave, and infrared communications), electronic communications, or other such communication means.

[0122] Although the invention has been described with reference to specific exemplary embodiments, it is noted that various modifications and changes may be made to these embodiments without departing from the broad scope of the invention. For example, the various operations, blocks, etc., described herein may be enabled and operated using hardware circuitry (for example, Complementary Metal Oxide Semiconductor (CMOS) based logic circuitry), firmware, software, and / or any combination of hardware, firmware, and / or software (for example, embodied in a machine-readable medium). For example, the apparatuses and methods may be embodied using transistors, logic gates, and electrical circuits (for example, Application Specific Integrated Circuit (ASIC) circuitry and / or Digital Signal Processor (DSP) circuitry).

[0123] Particularly, the server system 200 and its various components may be enabled using software and / or using transistors, logic gates, and electrical circuits (for example, integrated circuit circuitry such as ASIC circuitry). Various embodiments of the invention may include one or more computer programs stored or otherwise embodied on a computer-readable medium, wherein the computer programs are configured to cause the processor or the computer to perform one or more operations. A computer-readable medium storing, embodying, or encoded with a computer program, or similar language, may be embodied as a tangible data storage device storing one or more software programs that are configured to cause the processor or computer to perform one or more operations. Such operations may be, for example, any of the steps or operations described herein. In some embodiments, the computer programs may be stored and provided to a computer using any type of non-transitory computer- readable media. Non-transitory computer-readable media includes any type of tangible storage media.

[0124] Examples of non-transitory computer-readable media include magnetic storage media (such as floppy disks, magnetic tapes, hard disk drives, etc.), optical magnetic storage media (e.g. magneto-optical disks), Compact Disc Read-Only Memory (CD-ROM ), Compact Disc Recordable (CD-R), compact disc rewritable (CD-R / W), Digital Versatile Disc (DVD), BLU-RAY® Disc (BD), and semiconductor memories (such as mask ROM, programmable ROM (PROM), (erasable PROM), flash memory, Random Access Memory (RAM), etc.).Additionally, a tangible data storage device may be embodied as one or more volatile memory devices, one or more non-volatile memory devices, and / or a combination of one or more volatile memory devices and non-volatile memory devices. In some embodiments, the computer programs may be provided to a computer using any type of transitory computer- readable media. Examples of transitory computer-readable media include electric signals, optical signals, and electromagnetic waves. Transitory computer-readable media can provide the program to a computer via a wired communication line (e.g., electric wires, and optical fibers) or a wireless communication line.

[0125] Various embodiments of the invention, as discussed above, may be practiced with steps and / or operations in a different order, and / or with hardware elements in configurations, which are different than those which are disclosed. Therefore, although the invention has been described based on these exemplary embodiments, it is noted that certain modifications, variations, and alternative constructions may be apparent and well within the scope of the invention.

[0126] Although various exemplary embodiments of the invention are described herein in a language specific to structural features and / or methodological acts, the subject matter defined in the appended claims is not necessarily limited to the specific features or acts described above. Rather, the specific features and acts described above are disclosed as exemplary forms of implementing the claims.

Claims

CLAIMS1. A computer- implemented method for unified Application Programming Interface (API) configuration (config) at a plurality of operational levels in an API ecosystem, the computer-implemented method comprising: receiving a plurality of API config files for the plurality of operational levels, each API config file for an operational level comprising a user selection of a service provider platform from among a plurality of service provider platforms for facilitating an API service; assigning a plurality of interface worker entities to the plurality of operational levels based, at least in part, on the plurality of API config files; configuring, by the plurality of interface worker entities, a plurality of provider- specific API config files for the plurality of service provider platforms from the plurality of API config files based, at least in part, on a predefined design ruleset; and implementing, by the plurality of interface worker entities, the plurality of providerspecific API config files on the plurality of service provider platforms based, at least in part, on the user selection.

2. The computer-implemented method as claimed in claim 1, further comprising: upon implementation of the plurality of provider- specific API config files on the plurality of service provider platforms, generating a configuration control interface for facilitating an adjustment of one or more parameters defined in each of the plurality of provider- specific API config files for each operational level.

3. The computer- implemented method as claimed in claim 1, wherein assigning the plurality of interface worker entities comprises assigning the plurality of interface worker entities to the plurality of operational levels upon validation of the plurality of API config files based at least on the predefined design ruleset.

4. The computer- implemented method as claimed in claim 1, wherein the plurality of operational levels comprises a service mesh level, an API gateway level, and an edge computing level.

5. The computer-implemented method as claimed in any of claims 1 and 4, wherein implementing the plurality of provider- specific API config files on the plurality of service provider platforms comprises performing: generating a proxy API on a gateway service provider platform of the plurality of service provider platforms; configuring the proxy API for facilitating an API gateway-level service for the API gateway-level based, at least in part, on a gateway provider- specific API config file of the plurality of provider- specific API config files; and configuring a mesh service provider platform of the plurality of service provider platforms for facilitating a mesh-level service for the service mesh level based, at least in part, on a mesh provider- specific API config file of the plurality of providerspecific API config files; and configuring an edge service provider platform of the plurality of service provider platforms for facilitating an edge-level service for the edge computing level based, at least in part, on an edge provider- specific API config file of the plurality of provider- specific API config files, wherein each of the plurality of provider- specific API config files comprises one or more parameters that are defined to be interoperable between the plurality of operational levels and the plurality of service provider platforms.

6. The computer- implemented method as claimed in any of claims 1 and 5, further comprising: determining whether the one or more parameters defined in the plurality of providerspecific API config files for the plurality of service provider platforms are interoperable between the plurality of operational levels based, at least in part, on a comparison of the one or more parameters between the plurality of operational levels; and upon determining that the one or more parameters are not interoperable, fine-tuning the one or more parameters for at least one of the plurality of operational levels based, at least in part, on a predefined interoperability criterion.

7. The computer-implemented method as claimed in claim 1, further comprising: integrating the plurality of service provider platforms at each of the plurality of interface worker entities based, at least in part, on the user selection.

8. The computer- implemented method as claimed in any of claims 1 and 7, wherein each interface worker entity is configured to provision a plurality of service provider platform- specific resources corresponding to the plurality of service provider platforms integrated at the corresponding interface worker entity, required for the unified API configuration.

9. The computer-implemented method as claimed in claim 1, further comprising: facilitating a preparation of the plurality of API config files for the plurality of operational levels based, at least in part, on predefined policies and rules, the plurality of API config files being service provider- agnostic.

10. A server system, comprising: a communication interface; a memory configured to store instructions; and a processor in communication with the communication interface and the memory, the processor configured to execute the instructions stored in the memory and thereby cause the server system to perform at least in part to: receive a plurality of API config files for a plurality of operational levels, each API config file for an operational level comprising a user selection of a service provider platform from among a plurality of service provider platforms for facilitating an API service; assign a plurality of interface worker entities to the plurality of operational levels based, at least in part, on the plurality of API config files; configure, by the plurality of interface worker entities, a plurality of provider- specific API config files for the plurality of service provider platforms from the plurality of API config files based, at least in part, on a predefined design ruleset; and implement, by the plurality of interface worker entities, the plurality of providerspecific API config files on the plurality of service provider platforms based, at least in part, on the user selection.

11. The server system as claimed in claim 10, wherein the server system is caused, at least in part, to: assign the plurality of interface worker entities to the plurality of operational levelsupon validation of the plurality of API config files based at least on the predefined design ruleset, wherein the plurality of operational levels comprises a service mesh level, an API gateway level, and an edge computing level.

12. The server system as claimed in any of claims 10 and 11, wherein the server system is caused, at least in part, to implement the plurality of provider- specific API config files on the plurality of service provider platforms by performing: generating a proxy API on a gateway service provider platform of the plurality of service provider platforms; configuring the proxy API for facilitating an API gateway-level service for the API gateway-level based, at least in part, on a gateway provider- specific API config file of the plurality of provider- specific API config files; and configuring a mesh service provider platform of the plurality of service provider platforms for facilitating a mesh-level service for the service mesh level based, at least in part, on a mesh provider- specific API config file of the plurality of providerspecific API config files; and configuring an edge service provider platform of the plurality of service provider platforms for facilitating an edge-level service for the edge computing level based, at least in part, on an edge provider- specific API config file of the plurality of provider- specific API config files, wherein each of the plurality of provider- specific API config files comprises one or more parameters that are defined to be interoperable between the plurality of operational levels and the plurality of service provider platforms.

13. The server system as claimed in any of claims 10 and 12, wherein the server system is further caused, at least in part, to: determine whether the one or more parameters defined in the plurality of providerspecific API config files for the plurality of service provider platforms are interoperable between the plurality of operational levels based, at least in part, on a comparison of the one or more parameters between the plurality of operational levels; and upon determining that the one or more parameters are not interoperable, fine-tune the one or more parameters for at least one of the plurality of operational levels based, at least in part, on a predefined interoperability criterion.

14. The server system as claimed in claim 10, wherein the server system is further caused, at least in part, to: integrate the plurality of service provider platforms at each of the plurality of interface worker entities based, at least in part, on the user selection.

15. A non-transitory computer-readable storage medium comprising computer-executable instructions that, when executed by at least a processor of a server system, cause the server system to perform a method comprising: receiving a plurality of API config files for the plurality of operational levels, each API config file for an operational level comprising a user selection of a service provider platform from among a plurality of service provider platforms for facilitating an API service; assigning a plurality of interface worker entities to the plurality of operational levels based, at least in part, on the plurality of API config files; configuring, by the plurality of interface worker entities, a plurality of provider- specific API config files for the plurality of service provider platforms from the plurality of API config files based, at least in part, on a predefined design ruleset; and implementing, by the plurality of interface worker entities, the plurality of providerspecific API config files on the plurality of service provider platforms based, at least in part, on the user selection.

Images