Description:TECHNICAL FIELD
[0001] The present disclosure relates generally to defining Application Programming Interfaces (APIs). In particular, the present disclosure relates to a method and a system for defining container-agnostic APIs.

BACKGROUND
[0002] The following description of the related art is intended to provide background information pertaining to the field of the disclosure. This section may include certain aspects of the art that may be related to various features of the present disclosure. However, it should be appreciated that this section is used only to enhance the understanding of the reader with respect to the present disclosure, and not as admission of the prior art.
[0003] The introduction of containers has allowed applications to be run in isolated and portable environments. This has enabled developers to easily deploy and scale applications without having to worry about underlying infrastructure. However, the use of containers has created new challenges around the portability of application programming interfaces (APIs). Existing solutions for defining APIs are often tightly coupled to the specific container declarations in which the API is to be hosted. This introduces an overhead for application developers to understand the container specifics and makes it difficult to upgrade or switch containers, thus causing platform lock-ins. Different container runtimes have different formats for expressing APIs, making it difficult for developers to create APIs that are portable across different container runtimes. Furthermore, the highly fragmented container market also makes it difficult to agree on common standards for container declarations.
[0004] Additionally, there is an increasing need for extensible APIs. Many applications are built on top of a core layer that provides a set of predefined APIs. It is difficult to extend such APIs as there is not an easy way to override the predefined APIs. As such, there is a need for a more flexible and extensible way of declaring APIs that can be portable across different container runtimes. Further, existing solutions that try to address the aforementioned problems, such as OpenApi, impose other limitations on the API design, such as limiting the API to operate on a small set of transport protocols, among others. Existing solutions also do not allow for decoupling of business logic from API declarations, which may be important for scaling and maintainability.
[0005] Therefore, there is a need for a method and a system for solving the shortcomings of the existing solutions, by providing a method and system for defining container-agnostic APIs.

OBJECTS OF THE INVENTION
[0006] Some of the objects of the present disclosure, which at least one embodiment herein satisfies are listed herein below.
[0007] An object of the present disclosure is to provide a method and a system for defining container-agnostic Application Programming Interfaces (APIs).
[0008] Another object of the present disclosure is to provide a method and a system for expressing API definitions in a Domain Specific Language (DSL) such that the API definitions can be decoupled from the API declarations.
[0009] Another object of the present disclosure is to provide a method and a system for defining container agnostic APIs where the business logic is decoupled from the API declarations.
[0010] Another object of the present disclosure is to provide a method and a system for defining APIs that are compatible with a variety of transport protocols.
[0011] Another object of the present disclosure is to provide a method and a system for defining APIs that are extensible in multi-layered architectures.
[0012] Another object of the present disclosure is to make the container specific implementation transparent to an application developer.
[0013] Yet another object of the present disclosure is to provide a method and a system for defining APIs with modifiable parsers based on requirements.
[0014] The other objects and advantages of the present disclosure will be apparent from the following description when read in conjunction with the accompanying drawings, which are incorporated for illustration of the preferred embodiments of the present disclosure and are not intended to limit the scope thereof.

SUMMARY
[0015] This section is provided to introduce certain objects and aspects of the present disclosure in a simplified form that are further described below in the detailed description. This summary is not intended to identify the key features or the scope of the claimed subject matter.
[0016] Aspects of the present disclosure relate generally to defining Application Programming Interfaces (APIs). In particular, the present disclosure relates to a method and a system for defining container-agnostic APIs.
[0017] In an aspect, a method for defining container-agnostic API includes receiving, by a processor, an API definition expressed in a domain specific language (DSL) query, the API definition having at least one endpoint for receiving a request payload, at least one lambda function that generates a response payload based on the received request payload, and one or more data schema associated with the request payload and the response payload that are expressed in the DSL query, parsing, by the processor, the received API definition into an executable data structure representation of the DSL query, executing, by the processor, said data structure representation based on a predefined instruction set associated with the DSL query, where the predefined instruction set includes generating, by the processor, a container-agnostic API definition based on the executable data structure representation and a mapping of said container-agnostic API definition to a predetermined set of attributes common to each container runtime, packaging, by the processor, the container-agnostic API definition and associated dependencies into a container image and creating a container corresponding to the packaged container image.
[0018] In an embodiment, the container-agnostic API definition may be extensible using one or more plugins, where the one or more plugins may enable modification and overriding of existing API definition.
[0019] In an embodiment, a business logic associated with the API may be decouplable from the container, where the business logic may be callable using the at least one lambda function.
[0020] In an embodiment, the API definition expressed in the DSL query may be compatible with a plurality of transport protocols associated with the container used for receiving the request payload and transmitting the response payload.
[0021] In an embodiment, the API definition expressed in the DSL query may be parsed using a modifiable parser customized based on requirements.
[0022] In an aspect, a system for defining container-agnostic API includes a processor, and a memory coupled to the processor, where the memory includes processor-executable instructions, which on execution, cause the processor to receive an API definition expressed in a DSL query, the API definition having at least one endpoint for receiving a request payload, at least one lambda function that generates a response payload based on the received request payload, and one or more data schema associated with the request payload and the response payload that are expressed in the DSL query, parse the received API definition into an executable data structure representation of the DSL query, execute said data structure representation based on a predefined instruction set associated with the DSL query, where the predefined instruction set causes the processor to generate a container-agnostic API definition based on the data structure representation and a mapping of said container-agnostic API definition to a predetermined set of attributes common to each container runtime, package the container-agnostic API definition and associated dependencies into a container image and create a container corresponding to the packaged container image.
[0023] In an embodiment, the container-agnostic API definition may be extensible using one or more plugins, where the one or more plugins may enable modification and overriding of existing API definition.
[0024] In an embodiment, a business logic associated with the API may be decouplable from the container, where the business logic may be callable using the at least one lambda function.
[0025] In an embodiment, the API definition expressed in the DSL query may be compatible with a plurality of transport protocols associated with the container used for receiving the request payload and transmitting the response payload.
[0026] In an embodiment, the API definition expressed in the DSL query may be parsed using a modifiable parser customized based on requirements.
[0027] In an aspect, a non-transitory computer-readable medium includes processor-executable instructions that cause a processor to receive an API definition expressed in a DSL query, the API definition having at least one endpoint for receiving a request payload, at least one lambda function that generates a response payload based on the received request payload, and one or more data schema associated with the request payload and the response payload that are expressed in the DSL query, parse the received API definition into an executable data structure representation of the DSL query, execute said data structure representation based on a predefined instruction set associated with the DSL query, where the predefined instruction set causes the processor to generate a container-agnostic API definition based on the data structure representation and a mapping of said container-agnostic API definition to a predetermined set of attributes common to each container runtime, package the container-agnostic API definition and associated dependencies into a container image and create a container corresponding to the packaged container image.
[0028] Various objects, features, aspects, and advantages of the inventive subject matter will become more apparent from the following detailed description of preferred embodiments, along with the accompanying drawing figures in which like numerals represent like components.

BRIEF DESCRIPTION OF THE DRAWINGS
[0029] The accompanying drawings are included to provide a further understanding of the present disclosure and are incorporated in and constitute a part of this specification. The drawings illustrate exemplary embodiments of the present disclosure and, together with the description, serve to explain the principles of the present disclosure.
[0030] FIG. 1 illustrates an exemplary network architecture for implementing a proposed system for defining container-agnostic Application Programming Interfaces (APIs), according to embodiments of the present disclosure.
[0031] FIG. 2 illustrates an exemplary detailed block diagram of the proposed system, according to embodiments of the present disclosure.
[0032] FIG. 3 illustrates an exemplary flow diagram for defining container-agnostic APIs, according to embodiments of the present disclosure.
[0033] FIG. 4 illustrates a flow chart of a method for defining container-agnostic APIs, according to embodiments of the present disclosure.
[0034] FIG. 5 illustrates a hardware platform with which or in which embodiments of the present disclosure may be implemented.
[0035] The foregoing shall be more apparent from the following more detailed description of the disclosure.

DETAILED DESCRIPTION
[0036] In the following description, for the purposes of explanation, various specific details are set forth in order to provide a thorough understanding of the embodiments of the present disclosure. It will be apparent, however, that embodiments of the present disclosure may be practiced without these specific details. Several features described hereafter can each be used independently of one another or with any combination of other features. An individual feature may not address all of the problems discussed above or might address only some of the problems discussed above. Some of the problems discussed above might not be fully addressed by any of the features described herein.
[0037] The ensuing description provides exemplary embodiments only, and is not intended to limit the scope, applicability, or configuration of the disclosure. Rather, the ensuing description of the exemplary embodiments will provide those skilled in the art with an enabling description for implementing an exemplary embodiment. It should be understood that, various changes may be made in the function and arrangement of elements without departing from the spirit and scope of the disclosure as set forth.
[0038] Specific details are given in the following description to provide a thorough understanding of the embodiments. However, it will be understood by one of ordinary skill in the art that the embodiments may be practiced without these specific details. For example, circuits, systems, networks, processes, and other components may be shown as components in block diagram form in order not to obscure the embodiments in unnecessary detail. In other instances, well-known circuits, processes, algorithms, structures, and techniques may be shown without unnecessary detail in order to avoid obscuring the embodiments.
[0039] Also, it is noted that individual embodiments may be described as a process which is depicted as a flowchart, a flow diagram, a data flow diagram, a structure diagram, or a block diagram. Although a flowchart may describe the operations as a sequential process, many of the operations can be performed in parallel or concurrently. In addition, the order of the operations may be re-arranged. A process is terminated when its operations are completed but could have additional steps not included in a figure. A process may correspond to a method, a function, a procedure, a subroutine, a subprogram, etc. When a process corresponds to a function, its termination can correspond to a return of the function to the calling function or the main function.
[0040] The word “exemplary” and/or “demonstrative” is used herein to mean serving as an example, instance, or illustration. For the avoidance of doubt, the subject matter disclosed herein is not limited by such examples. In addition, any aspect or design described herein as “exemplary” and/or “demonstrative” is not necessarily to be construed as preferred or advantageous over other aspects or designs, nor is it meant to preclude equivalent exemplary structures and techniques known to those of ordinary skill in the art. Furthermore, to the extent that the terms “includes,” “has,” “contains,” and other similar words are used in either the detailed description or the claims, such terms are intended to be inclusive—in a manner similar to the term “comprising” as an open transition word—without precluding any additional or other elements.
[0041] As used herein, “connect,” “configure,” “couple” and its cognate terms, such as “connects,” “connected,” “configured,” and “coupled” may include a physical connection (such as a wired/wireless connection), a logical connection (such as through logical gates of semiconducting device), other suitable connections, or a combination of such connections, as may be obvious to a skilled person.
[0042] As used herein, “send,” “transfer,” “transmit,” and their cognate terms like “sending,” “sent,” “transferring,” “transmitting,” “transferred,” “transmitted,” etc. include sending or transporting data or information from one unit or component to another unit or component, wherein the content may or may not be modified before or after sending, transferring, transmitting.
[0043] Reference throughout this specification to “one embodiment” or “an embodiment” or “an instance” or “one instance” 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. Thus, the appearances of the phrases “in one embodiment” or “in an embodiment” in various places throughout this specification are not necessarily all referring to the same embodiment. Furthermore, the particular features, structures, or characteristics may be combined in any suitable manner in one or more embodiments.
[0044] The terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting of the disclosure. As used herein, the singular forms “a,” “an,” and “the” are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will be further understood that the terms “comprises” and/or “comprising,” when used in this specification, specify the presence of stated features, integers, steps, operations, elements, and/or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and/or groups thereof. As used herein, the term “and/or” includes any and all combinations of one or more of the associated listed products.
[0045] Various embodiments of the present disclosure provide a method and a system for container-agnostic Application Programming Interface (API). Embodiments explained herein relate generally to defining APIs. In particular, the present disclosure relates to a method and a system for defining container-agnostic APIs.
[0046] The present disclosure provides a method and a system for defining container-agnostic APIs. The present disclosure provides a method and a system for expressing API definitions in a Domain Specific Language (DSL) such that the API definitions can be decoupled from the API declarations. The present disclosure provides a method and a system for defining container-agnostic APIs where the business logic is decoupled from the API declarations. The present disclosure provides a method and a system for defining APIs that are compatible with a variety of transport protocols. The present disclosure provides a method and a system for defining APIs that are extensible in multi-layered architectures. The present disclosure provides a method and a system to make the container specific implementation transparent to an application developer. The present disclosure provides a method and a system for defining APIs with modifiable parsers based on requirements.
[0047] Other like benefits and advantages are provided by the disclosed solution, which will be discussed in detail throughout the disclosure. The various embodiments throughout the disclosure will be explained in more detail with reference to FIGs. 1-5.
[0048] FIG. 1 illustrates an exemplary network architecture 100 for implementing a system 110 for defining container-agnostic APIs, according to embodiments of the present disclosure. The network architecture 100 may include an electronic device 108, the system 110, and a centralized server 118. The system 110 may be connected to the centralized server 118 via a communication network 106.
[0049] In an embodiment, the centralized server 118 may include, but is not limited to, a stand-alone server, a remote server, a cloud computing server, a dedicated server, a rack server, a server blade, a server rack, a bank of servers, a server farm, hardware supporting a part of a cloud service or system, a home server, hardware running a virtualized server, one or more processors executing code to function as a server, one or more machines performing server-side functionality as described herein, at least a portion of any of the above, some combination thereof, and the like.
[0050] In an embodiment, the communication network 106 may be a wired communication network or a wireless communication network. The wireless communication network may be any wireless communication network capable of transferring data between entities of that network such as, but are not limited to, a Bluetooth, a Zigbee, a Near Field Communication (NFC), a Wireless-Fidelity (Wi-Fi) network, a Light Fidelity (Li-FI) network, a carrier network including a circuit-switched network, a packet switched network, a Public Switched Telephone Network (PSTN), a Content Delivery Network (CDN) network, an Internet, intranets, Local Area Networks (LANs), Wide Area Networks (WANs), mobile communication networks including a Second Generation (2G), a Third Generation (3G), a Fourth Generation (4G), a Fifth Generation (5G), a Sixth Generation (6G), a Long-Term Evolution (LTE) network, a New Radio (NR), a Narrow-Band (NB), an Internet of Things (IoT) network, a Global System for Mobile Communications (GSM) network and a Universal Mobile Telecommunications System (UMTS) network, combinations thereof, and the like.
[0051] In an embodiment, the system 110 may be implemented by way of a single device or a combination of multiple devices that may be operatively connected or networked together. For example, the system 110 may be implemented by way of a standalone device such as the centralized server 118, and the like, and may be communicatively coupled to the electronic device 108. In another embodiment, the system 110 may be implemented in/associated with the electronic device 108. In yet another embodiment, the system 110 may be implemented in/associated with respective computing devices (104-1, 104-2….104-N) (individually referred as the computing device 104 and collectively referred as the computing devices 104), associated with one or more users (102-1, 102-2….102-N) (individually referred as the user 102 and collectively referred as the users 102). In such a scenario, the system 110 may be replicated in each of the computing devices 104, wherein the users 102 may interact with said computing devices 104 for defining container-agnostic APIs.
[0052] In an embodiment, the electronic device 108 and/or the computing device 104 may be at least one of: an electrical, an electronic, an electromechanical, and a wireless computing device. The electronic device 108 and/or the computing device 104 may include, but is not limited to, a mobile device, a smart-phone, a Personal Digital Assistant (PDA), a tablet computer, a phablet computer, a wearable computing device, a Virtual Reality/Augmented Reality (VR/AR) device, a laptop, a desktop, a server, and the like.
[0053] In an embodiment, the system 110 may be implemented in hardware or a suitable combination of hardware and software. Referring to FIG. 1, the system 110 may include a processor 112, an Input/Output (I/O) interface 114, and a memory 116. The I/O interface 114 may be used to receive inputs from the computing devices 104 associated with the users 102. Further, the system 110 may also include other units such as a display unit, and the like, however the same are not shown in FIG. 1, for the purpose of clarity. Also, in FIG. 1, only a few units are shown, however, the system 110 or the network architecture 100 may include multiple such units or the system 110/ network architecture 100 may include any such numbers of the units, obvious to a person skilled in the art or as required to implement the features of the present disclosure.
[0054] In an embodiment, the system 110 may be a hardware device including the processor 112 executing computer-readable program instructions to define container-agnostic APIs. Execution of the computer-readable/machine-readable program instructions by the processor 112 may enable the system 110 to define container-agnostic APIs. The “hardware” may comprise a combination of discrete components, an integrated circuit, an application-specific integrated circuit, a field programmable gate array, a digital signal processor, or other suitable hardware. The “software” may comprise one or more objects, agents, threads, lines of code, subroutines, separate software applications, two or more lines of code, or other suitable software structures operating in one or more software applications or on one or more processors. The processor 112 may include, for example, but is not limited to, microprocessors, microcomputers, microcontrollers, digital signal processors, central processing units, state machines, logic circuits, and any devices that manipulate data or signals based on operational instructions, and the like. Among other capabilities, the processor 112 may fetch and execute computer-readable instructions in the memory 116 operationally coupled with the system 110 for performing tasks such as data processing, input/output processing, feature extraction, and/or any other functions. Any reference to a task in the present disclosure may refer to an operation being or that may be performed on data.
[0055] In the example that follows, assume that a user 102 of the system 110 desires to use the system 110 for defining container-agnostic APIs. In this instance, the user 102 may include any entity including, but not limited to, software developers, programmers, end-users, software testers, enterprise customers, end users, content providers, web developers, system integrators, database administrators, and the like, who may operate the system 110 for defining container-agnostic APIs. The system 110, when associated with the electronic device 108 or the centralized server 118, may include, but is not limited to, a touch panel, a soft keypad, a hard keypad (including buttons), and the like, through which the user 102 operates said system 110.
[0056] In an embodiment, the system 110 for defining container-agnostic APIs may, through the processor 112, receive an API definition expressed in a DSL query. In an embodiment, the API definition may have at least one endpoint for receiving a request payload, at least one lambda function that generates a response payload based on the received request payload, and one or more data schema associated with the request payload and the response payload that are expressed in the DSL query. In an embodiment, the DSL query may be designed to include a set of language constructs indicative of grammar rules or syntaxes that may be used to define the container-agnostic APIs. In an embodiment, the set of language constructs may be indicative of modules of computer-readable instructions that may return an output when executed by the processor 112. The set of language constructs may be determined based on attributes common to each type of container runtime. For example, the DSL query may include grammar rules for defining a variable type, a data type, a variable scope, a data structure, a data mapping, an authorization, an authentication, and the like. In an embodiment, the DSL query may allow the user 102 to express API definitions in human-readable queries, and create APIs of in the required API design in accordance with the set of language constructs associated with the DSL query. In an embodiment, the user 102 may provide at least one endpoint indicative of a Uniform Resource Locator (URL), and may define request verbs associated with each endpoint such as ‘GET’, ‘POST’, ‘PUT’, and/or ‘DELETE’, query parameters, and the like, in the DSL query. In an embodiment, the user 102 may also express lambda functions to generate the response payload based on the received request payload. In an embodiment, the lambda functions may invoke one or more business logic elements stored at a backend architecture associated with the API. In an embodiment, the user 102 may also express the data schema associated with the request payload and the response payload in the DSL query.
[0057] In an embodiment, the system 110 may parse the received API definition into an executable data structure representation of the DSL query. In an embodiment, the system 110 may parse the DSL query into the data structure representation indicative of including, but not limited to, a directed acyclic graph (DAG), a tree, a query graph, and the like. Further, each data structure representation may include one or more objects that represent language constructs of the API definition expressed in the DSL query. In an embodiment, the system 110 may parse the API definition expressed in the DSL query into the DAG representation of the API definition, wherein the DAG representation may include one or more nodes, each node representing a language construct present in the API definition expressed in the DSL query. For example, each node in the DAG representation may represent one or more language constructs of the DSL query, such as an endpoint, a lambda function, a data schema, a variable, and the like. It may be appreciated by those skilled in the art that while the present disclosure describes an embodiment parsing the API query expressed in DSL into executable data representation indicative of DAGs, elements of the present disclosure may be suitably adapted or modified to use other data structure representations depending on the use case. In other embodiments, the system 110 may parse the DSL query into data structure representations in general purpose languages native to the system 110 or the container runtime. For example, the system 110 may parse DSL query into an executable python code.
[0058] In an embodiment, the system 110 may then execute said data structure representation based on a predefined instruction set associated with the DSL query. In an embodiment, the predefined instruction set may cause the system 110 to generate a container-agnostic API definition based on the data structure representation and a mapping of said container-agnostic API definition to a predetermined set of attributes common to each container runtime. In an embodiment, the predefined instruction set associated with the DSL query may be indicative of executable logic, methods, or functions associated with each of the set of language constructs of the DSL query. In an embodiment, the predetermined set of attributes associated with the container runtimes may include definitions for allocating resources, establishing a communication channel, defining a variable type, data type, variable scope, data structure, data mapping, authorization, authentication, and the like. In an embodiment, the predefined instruction set may include instructions to generate definitions for APIs that are compatible with the differing runtime requirements of each type of container. For instance, the container runtimes including, but not limited to, Kubernetes, Docker, OpenShift, and the like, may have differing runtime requirements such as requiring different image formats, differing host Operating System (OS) requirements, and the like. In such embodiments, the system 110, by executing the data structure representation, may generate definitions for APIs with attributes that are common to each of the container runtimes, which may be suitably retrieved and used by each type of container runtime during deployment. In an embodiment, once the container-agnostic API definition is generated, the system 110 may generate a mapping of said container-agnostic API definition to a predetermined set of attributes common to each container runtime to allow each container runtime to interpret the container-agnostic API definition and retrieve the appropriate attributes for execution.
[0059] In an embodiment, the predefined instruction set may also include instructions to package said container-agnostic API definition and associated dependencies into a container image. In an embodiment, the container image may include, but is not limited to, a Docker image, a Kubernetes image, a Mesos image, or the like. The container image may be created using any containerization technology, wherein the container image may include the container-agnostic API definition, the associated dependency modules or libraries, and other runtime requirement attributes packaged into a single, immutable container image. In an embodiment, the container image may be registered under a container registry. In an embodiment, the system 110 may create a container corresponding to the packaged container image, wherein the container may be created by executing the container image using a container engine. In an embodiment, the container may be deployed using a container orchestrator (for example, 150 of FIG. 3) associated with the container engine.
[0060] In an embodiment, the container-agnostic API definition may be extensible using one or more plugins, and wherein the one or more plugins may enable modification and overriding of existing API definition. In an embodiment, the one or more plugins may be indicative of additional instructions and/or declarations, which enable the existing container-agnostic API definition to be modified and/or augmented. In an embodiment, the one or more plugins may be packaged within the container image, wherein the one or more plugins may be configured to be executed by the container. In an embodiment, the one or more plugins may override the instructions and/or declaration in the container-agnostic API definition.
[0061] In an embodiment, a business logic associated with the API may be decouplable from the container, said business logic being callable using the at least one lambda function. In an embodiment, the lambda function may be configured to send a request to the backend application associated with the API, which initiates a call to invoke the business logic stored therein. The backend may then execute the invoked business logic, and the result may be returned to the lambda function, thereby allowing the business logic to be decoupled from the container.
[0062] In an embodiment, the API definition expressed in the DSL query may be compatible with a variety of transport protocols associated with the container used for receiving the request payload and transmitting the response payload. In an embodiment, the DSL query may be designed to be compatible with transport protocols including, but not limited to, Representational State Transfer (REST) protocol, Hypertext Transfer Protocol (HTTP), Simple Object Access Protocol (SOAP), and the like.
[0063] In an embodiment, the API definition expressed in the DSL query may be parsed using a modifiable parser customized based on requirements. In an embodiment, the parser may be customized to allow the DSL query to be parsed suitably in accordance to any changes in container runtime requirements or standards.
[0064] In an embodiment, a non-transitory computer-readable medium includes processor-executable instructions that cause a processor to, receive an API definition expressed in a DSL query, said API definition having at least one endpoint for receiving a request payload, at least one lambda function that generates a response payload based on the received request payload, and one or more data schema associated with the request payload and the response payload that are expressed in the DSL query, parse the received API definition into an executable data structure representation of the DSL query, execute said data structure representation based on a predefined instruction set associated with the DSL query, said predefined instruction set causing the processor to generate a container-agnostic API definition based on the data structure representation and a mapping of said container-agnostic API definition to a predetermined set of attributes common to each container runtime, package said container-agnostic API definition and associated dependencies into a container image and create a container corresponding to the packaged container image.
[0065] Although FIG. 1 shows exemplary components of the network architecture 100, in other embodiments, the network architecture 100 may include fewer components, different components, differently arranged components, or additional functional components than depicted in FIG. 1. Additionally, or alternatively, one or more components of the network architecture 100 may perform functions described as being performed by one or more other components of the network architecture 100.
[0066] FIG. 2 illustrates an exemplary detailed block diagram of the proposed system, according to embodiments of the present disclosure. As shown, the system 110 may include the processor 112, the I/O interface 114, the memory 116, and one or more modules 204. In an embodiment, the memory 116 may include data 202.
[0067] In an embodiment, the data 202 may include DSL query data 206, DSL grammar data 208, parsed data structure 210, instruction set data 212, container runtime data 214, and other data 216. In an embodiment, the data 202 may be stored in the memory 116 in the form of various data structures. Additionally, the data 202 may be organized using data models, such as relational or hierarchical data models. The other data 216 may store data, including temporary data and temporary files, generated by the modules 204 for performing the various functions of the system 110.
[0068] In an embodiment, the modules 204 may include a receiving module 218, a parsing module 220, an executing module 222, a packaging module 224, a container engine module 226, a transmitting module 228, and other modules 230.
[0069] In an embodiment, the data 202 stored in the memory 116 may be processed by the modules 204 of the system 110. The modules 204 may be stored within the memory 116. In an example, the modules 204, communicatively coupled to the processor 112 configured in the system 110, may also be present outside the memory 116, as shown in FIG. 2, and implemented as hardware. As used herein, the term modules may refer to an Application-Specific Integrated Circuit (ASIC), an electronic circuit, a processor (shared, dedicated, or group) and memory that execute one or more software or firmware programs, a combinational logic circuit, and/or other suitable components that provide the described functionality.
[0070] In an embodiment, the receiving module 218 may receive an API definition expressed in a DSL query, said API definition having at least one endpoint for receiving a request payload, at least one lambda function that generates a response payload based on the received request payload, and one or more data schema associated with the request payload and the response payload that are expressed in the DSL query. In an embodiment, the receiving module 218 may receive the API definition as DSL query data 206 from the user 102. In an embodiment, the DSL query may be constructed using the set of language constructs associated with the DSL, said set of language constructs being stored as grammar rules in DSL grammar data 208.
[0071] In an embodiment, the parsing module 220 may parse the received API definition into an executable data structure representation of the DSL query. In an embodiment, the parsing module 220 may parse the DSL query into the data structure representation stored as parsed data structure 210. In an embodiment, the API definition expressed in the DSL query may be parsed using a modifiable parser customized based on requirements.
[0072] In an embodiment, the executing module 222 may execute said data structure representation based on a predefined instruction set associated with the DSL query. In an embodiment, the predefined instruction set may be stored as instruction set data 212. In an embodiment, the predefined instruction set may cause the processor to generate a container-agnostic API definition based on the data structure representation and a mapping of said container-agnostic API definition to a predetermined set of attributes common to each container runtime. In an embodiment, the set of attributes associated with the container runtime may be stored as container runtime data 214.
[0073] In an embodiment, the packaging module 224 may package said container-agnostic API definition and associated dependencies into the container image. In an embodiment, the container engine module 226 may create the container corresponding to the packaged container image. In an embodiment, the container engine module 226 may be installed as an application within the native operating system environment associated with the system 110. In other embodiments, the container engine module 226 may be an application available at a remote computer resource on a network. In such embodiments, the system 110 may transmit requests to the remote computer resources along with the container image to create the container. In an embodiment, the transmitting module 228 may transmit the container to the container orchestrator 150 for deployment.
Exemplary scenario
[0074] Consider a scenario where the user 102 wishes to define a container-agnostic API, as shown in FIG. 3. The system 110 may be configured to allow users 102 to define container-agnostic APIs by forming and transmitting API definitions expressed in a DSL query. In an example, the system 110 may include a Graphical User Interface (GUI) based text editor that allows users 102 to form and submit queries written in accordance with the set of language constructs associated with the DSL query. The user 102 may define the at least one endpoint, at least one lambda function, and data scheme associated with the request payload and the response payload, among other API definitions. In such examples, the system 110 may parse the DSL query received from the user 102 into the executable data structure representations. In an example, the data structure representations may then be executed based on a predefined instruction set associated with the DSL to generate a container-agnostic API definition and the mapping of said container-agnostic API definitions to a predetermined set of attributes common to each of the container runtimes. In an example, the system 110 may then package said container-agnostic API definition and associated dependencies into the container image such as a Docker image, and create the corresponding container such as a Docker file. Thereon, the container may be executed by a container orchestrator such as Kubernetes.
[0075] In the foregoing example, the container may also be deployed to provide API services. For example, the container-agnostic API may be configured to receive a request payload from a computing device 104 associated with the user 102, wherein the data schema associated with the request payload is in accordance with the API definition. Additionally, the container-agnostic API may be further configured to invoke the at least one lambda function based on the received request payload, wherein the at least one lambda function generates a response payload based on the received request payload. In an embodiment, the system 110 may be further configured to transmit the response payload to the computing device 104. The container-agnostic API may be extensible using one or more plugins. In an example, the container-agnostic API may be deployed using a container orchestrator 150, that may enable the deployed container-agnostic API to be modified using extensible hooks and/or installation of one or more plugins.
[0076] FIG. 4 illustrates a flow chart depicting a method 400 for defining container-agnostic API, according to embodiments of the present disclosure.
[0077] At step 402, the method includes receiving, by a processor such as the processors 112 of FIGs. 1 and 2 associated with a system such as system 110, an API definition expressed in a DSL query, said API definition having at least one endpoint for receiving a request payload, at least one lambda function that generates a response payload based on the received request payload, and one or more data schema associated with the request payload and the response payload that are expressed in the DSL query.
[0078] At step 404, the method includes parsing, by the processor 112, the received API definition into an executable data structure representation of the DSL query.
[0079] At step 406, the method includes executing, by the processor 112, said data structure representation based on a predefined instruction set associated with the DSL query. In an embodiment, the method may execute step 408 and step 410 from the predefined instruction set.
[0080] At step 408, the method includes generating, by the processor, a container-agnostic API definition based on the parsed executable data structure representation and a mapping of said container-agnostic API definition to a predetermined set of attributes common to each container runtime.
[0081] At step 410, the method includes packaging, by the processor, said container-agnostic API definition and associated dependencies into a container image and creating a container corresponding to the packaged container image.
[0082] It may be appreciated that the order in which the method 400 is described is not intended to be construed as a limitation, and any number of the described method steps may be combined or otherwise performed in any order to implement the method 400 or an alternate method. Additionally, individual steps may be deleted from the method 400 without departing from the scope of the present disclosure described herein. Furthermore, the method 400 may be implemented in any suitable hardware, software, firmware, or a combination thereof that exists in the related art or that is later developed. The method 400 describes, without limitation, the implementation of the system 110. Those skilled in the art will understand that method 400 may be modified appropriately for implementation in various manners without departing from the scope of the present disclosure.
[0083] FIG. 5 illustrates a hardware platform 500 with which or in which embodiments of the present disclosure may be implemented, according to an example embodiment of the present disclosure. For the sake of brevity, the construction, and operational features of the system 110 which are explained in detail above are not explained in detail herein. Particularly, computing machines such as but not limited to internal/external server clusters, quantum computers, desktops, laptops, smartphones, tablets, and wearables which may be used to execute the system 110 or may include the structure of the hardware platform 500 are not explained in detail herein. As illustrated, the hardware platform 500 may include additional components not shown, and that some of the components described may be removed and/or modified. For example, a computer system with multiple Graphics Processing Units (GPUs) may be located on external-cloud platforms or internal corporate cloud computing clusters, or organizational computing resources, and the like.
[0084] The hardware platform 500 may be a computer system such as the system 110 that may be used in accordance with the embodiments described herein. The computer system may represent a computational platform that includes components that may be in a server or another computer system. The computer system may execute, by a processor 505 (e.g., a single or multiple processors) or other hardware processing circuit, the methods, functions, and other processes described herein. These methods, functions, and other processes may be embodied as machine-readable instructions stored on a computer-readable medium, which may be non-transitory, such as hardware storage devices (e.g., random access memory (RAM), read-only memory (ROM), erasable, programmable ROM (EPROM), electrically erasable, programmable ROM (EEPROM), hard drives, and flash memory). The computer system may include the processor 505 that executes software instructions or code stored on a non-transitory computer-readable storage medium 510 to perform methods of the present disclosure. In an example, the modules 204, may be software codes or components performing these steps. For example, the modules may include a receiving module 218, a parsing module 220, an executing module 222, a packaging module 224, a container engine module 226, a transmitting module 228, and other modules 230.
[0085] The instructions on the computer-readable storage medium 510 are read and stored in a storage 515 or in random access memory (RAM). The storage 515 may provide space for keeping static data where at least some instructions could be stored for later execution. The stored instructions may be further compiled to generate other representations of the instructions and dynamically stored in the RAM such as 520. The processor 505 may read instructions from the RAM 520 and perform actions as instructed.
[0086] The computer system may further include an output device 525 to provide at least some of the results of the execution as output including, but not limited to, visual information to users, such as external agents. The output device 525 may include a display on computing devices and virtual reality glasses. For example, the display may be a mobile phone screen or a laptop screen. Graphical User Interfaces (GUIs) and/or text may be presented as an output on the display screen. The computer system may further include an input device 530 to provide a user or another device with mechanisms for entering data and/or otherwise interacting with the computer system. The input device 530 may include, for example, a keyboard, a keypad, a mouse, or a touchscreen. Each of the output device 525 and the input device 530 may be joined by one or more additional peripherals. For example, the output device 525 may be used to display the results.
[0087] A network communicator 535 may be provided to connect the computer system to a network and in turn to other devices connected to the network including, for instance, other clients, servers, data stores, and interfaces. A network communicator 535 may include, for example, a network adapter such as a Local Access Network (LAN) adapter or a wireless adapter. The computer system may include a data sources interface 540 to access a data source 545. The data source 545 may be an information resource. As an example, knowledge repositories and curated data may be examples of the data source 545.
[0088] The present disclosure, therefore, solves the need for a method and a system for defining container-agnostic APIs.
[0089] While the foregoing describes various embodiments of the disclosure, other and further embodiments of the disclosure may be devised without departing from the basic scope thereof. The scope of the disclosure is determined by the claims that follow. The disclosure is not limited to the described embodiments, versions, or examples, which are included to enable a person having ordinary skill in the art to make and use the disclosure when combined with information and knowledge available to the person having ordinary skill in the art.

ADVANTAGES OF THE INVENTION
[0090] The present disclosure provides a method and a system for defining container-agnostic application programming interfaces (APIs).
[0091] The present disclosure provides a method and a system for expressing API definitions in a Domain Specific Language (DSL) such that the API definitions can be decoupled from the API declarations.
[0092] The present disclosure provides a method and a system for defining container agnostic APIs where the business logic is decoupled from the API declarations.
[0093] The present disclosure provides a method and a system for defining APIs that are compatible with a variety of transport protocols.
[0094] The present disclosure provides a method and a system for defining APIs that are extensible in multi-layered architectures.
[0095] The present disclosure provides a method and a system to make the container-specific implementation transparent to an application developer.
[0096] The present disclosure provides a method and a system for defining APIs with modifiable parsers based on requirements.
, Claims:1. A method for defining container-agnostic Application Programming Interface (API), the method comprising:
receiving, by a processor, an API definition expressed in a domain specific language (DSL) query, said API definition having at least one endpoint for receiving a request payload, at least one lambda function that generates a response payload based on the received request payload, and one or more data schema associated with the request payload and the response payload that are expressed in the DSL query;
parsing, by the processor, the received API definition into an executable data structure representation of the DSL query; and
executing, by the processor, said data structure representation based on a predefined instruction set associated with the DSL query, said predefined instruction set comprising:
generating, by the processor, a container-agnostic API definition based on the parsed executable data structure representation and a mapping of said container-agnostic API definition to a predetermined set of attributes common to each container runtime; and
packaging, by the processor, said container-agnostic API definition and associated dependencies into a container image and creating a container corresponding to the packaged container image.
2. The method as claimed in claim 1, wherein the container-agnostic API definition is extensible using one or more plugins, and wherein the one or more plugins enable modification and overriding of existing API definition.
3. The method as claimed in claim 1, wherein a business logic associated with the API is decouplable from the container, said business logic being callable using the at least one lambda function.

4. The method as claimed in claim 1, wherein the API definition expressed in the DSL query is compatible with a variety of transport protocols associated with the container used for receiving the request payload and transmitting the response payload.
5. The method as claimed in claim 1, wherein the API definition expressed in the DSL query is parsed using a modifiable parser customized based on requirements.
6. A system for defining container-agnostic Application Programming Interface (API), the system comprising:
a processor; and
a memory coupled to the processor, wherein the memory comprises processor-executable instructions, which on execution, cause the processor to:
receive an API definition expressed in a domain specific language (DSL) query, said API definition having at least one endpoint for receiving a request payload, at least one lambda function that generates a response payload based on the received request payload, and one or more data schema associated with the request payload and the response payload that are expressed in the DSL query;
parse the received API definition into an executable data structure representation of the DSL query; and
execute said data structure representation based on a predefined instruction set associated with the DSL query, said predefined instruction set causing the processor to:
generate a container-agnostic API definition based on the data structure representation and a mapping of said container-agnostic API definition to a predetermined set of attributes common to each container runtime; and
package said container-agnostic API definition and associated dependencies into a container image and create a container corresponding to the packaged container image.
7. The system as claimed in claim 6, wherein the container-agnostic API definition is extensible using one or more plugins, and wherein the one or more plugins enable modification and overriding of existing API definition.
8. The system as claimed in claim 6, wherein a business logic associated with the API is decouplable from the container, said business logic being callable using the at least one lambda function.
9. The system as claimed in claim 6, wherein the API definition expressed in the DSL query is compatible with a variety of transport protocols associated with the container used for receiving the request payload and transmitting the response payload.
10. The system as claimed in claim 6, wherein the API definition expressed in the DSL query is parsed using a modifiable parser customized based on requirements.
11. A non-transitory computer-readable medium comprising processor-executable instructions that cause a processor to:
receive an Application Programming Interface (API) definition expressed in a domain specific language (DSL) query, said API definition having at least one endpoint for receiving a request payload, at least one lambda function that generates a response payload based on the received request payload, and one or more data schema associated with the request payload and the response payload that are expressed in the DSL query;
parse the received API definition into an executable data structure representation of the DSL query; and
execute said data structure representation based on a predefined instruction set associated with the DSL query, said predefined instruction set causing the processor to:
generate a container-agnostic API definition based on the data structure representation and a mapping of said container-agnostic API definition to a predetermined set of attributes common to each container runtime; and
package said container-agnostic API definition and associated dependencies into a container image and create a container corresponding to the packaged container image.