DESC:
FORM 2

THE PATENTS ACT, 1970
(39 of 1970)
&
THE PATENTS RULES, 2003

COMPLETE SPECIFICATION
(See section 10 and rule 13)
1. TITLE OF THE INVENTION
METHOD AND SYSTEM FOR MANAGING ENDPOINT FOR A SERVICE APPLICATION PROGRAMMING INTERFACE (API)

2. APPLICANT(S)
NAME NATIONALITY ADDRESS
JIO PLATFORMS LIMITED INDIAN OFFICE-101, SAFFRON, NR. CENTRE POINT, PANCHWATI 5 RASTA, AMBAWADI, AHMEDABAD 380006, GUJARAT, INDIA
3.PREAMBLE TO THE DESCRIPTION

THE FOLLOWING SPECIFICATION PARTICULARLY DESCRIBES THE NATURE OF THIS INVENTION AND THE MANNER IN WHICH IT IS TO BE PERFORMED.

FIELD OF THE INVENTION
[0001] The present invention relates to the field of telecommunications networks, and more specifically to a method and a system for dynamic endpoint management for Application Programming Interfaces (API) providers.
BACKGROUND OF THE INVENTION
[0002] The APIs (Application Programming Interfaces) serve as a crucial link between different software applications, enabling seamless communication and integration. They allow developers to access and utilize the functionalities and services provided by API providers. In the context of this invention, the focus is on the control and management of endpoints within an API ecosystem.
[0003] Traditionally, API configuration involved the use of static files, where endpoints and related details were defined at the outset and remained fixed throughout the runtime of an application. Any changes or updates to these endpoints required a laborious process involving program termination, manual modification of configuration files, and restarting the program. This approach resulted in significant downtime and disruptions in service, making it cumbersome and time-consuming for the API providers to adapt to evolving requirements and consumer demands.
[0004] Furthermore, in the context of a Diameter protocol (a signaling protocol used in telecommunication networks), managing the configuration files for endpoints presented additional challenges. Diameter is extensively used in 3GPP (Third Generation Partnership Project) networks, and while there are well-defined specifications for 3GPP providers, there is a lack of standardized methodology for non-3GPP, third-party, or custom application API providers.
[0005] The static nature of endpoint configuration files and the absence of dynamic control mechanisms posed a considerable hurdle in achieving runtime flexibility, scalability, and efficient management of API endpoints. Therefore, the need for a more streamlined and agile approach to endpoint management became evident, leading to the development of the present invention.
SUMMARY OF THE INVENTION
[0006] One or more embodiments of the present disclosure provide a system and a method for managing endpoint for a service API received from an API provider.
[0007] In one aspect of the present invention, a method of managing endpoint for a service API received from an API provider is provided. The method includes receiving, by one or more processors, a request for registering the service API from a user equipment. The request includes a plurality of service API endpoint details and configuration parameters associated with the service API. Further, the method includes searching, by the one or more processors, for the endpoint within a configuration file based on the plurality of service API endpoint details and the configuration parameters. Further, the method includes forwarding, by the one or more processors, the request to a Common API Framework (CAPIF) module, when the endpoint is found in the configuration file.
[0008] In an embodiment, further, the method includes updating, by the one or more processors, the configuration file with the details of the endpoint and the configuration parameters, when the endpoint is not found in the configuration file.
[0009] In an embodiment, updating the configuration file with the plurality of details of the endpoint and the configuration parameters adds the new endpoint into a system associated with the CAPIF module. The system manages a plurality of service APIs from a plurality of API providers.
[0010] In an embodiment, the configuration file is stored in an API database.
[0011] In an embodiment, the user equipment is associated with the API provider.
[0012] In an embodiment, upon detecting presence of the endpoint in the configuration file, the API provider is determined to be valid, and a plurality of credentials of the API provider is verified.
[0013] In an embodiment, the valid API provider is allowed to register a plurality of service APIs with the CAPIF module.
[0014] In an embodiment, the request is received via one of an interface (e.g., user interface (UI) or the like) and a command line interface (CLI) associated with the user equipment, and wherein one of the interface and the CLI facilitate the user equipment to send one or more requests for modifying the plurality of details of the endpoint and the configuration parameters.
[0015] In another aspect of the present invention, a system for managing endpoint for a service API received from an API provider is provided. The system includes a load balancer and a CAPIF module. The load balancer is configured to receive a request for registering the service API from a user equipment. The request includes a plurality of service API endpoint details and configuration parameters associated with the service API. Further, the load balancer is configured to search for the endpoint within a configuration file based on the plurality of service API endpoint details and the configuration parameters. Further, the load balancer is configured to forward the request to the CAPIF module, when the endpoint is found in the configuration file. The CAPIF module is configured to receive the request from the load balancer when the endpoint is found in the configuration file.
[0016] In an embodiment, one of the interface and the CLI associated with the user equipment enables routing of the request to the load balancer. The load balancer routes the request to the CAPIF module when the endpoint is found in the configuration file.
[0017] In an embodiment, one of: the interface and the CLI is configured to enable the user equipment of the API provider to interact with one or more modules of the system. One of: the interface and the CLI is configured to facilitate the user equipment to send the request for registering the service API. One of: the interface and the CLI is configured to facilitate the user equipment to send one or more requests for modifying the plurality of details of the endpoint and the configuration parameters.
[0018] In an embodiment, the load balancer is configured with a set of rules that determine a destination for each request.
[0019] In an embodiment, the CAPIF module is further configured to update the configuration file with the plurality of details of the endpoint and the configuration parameters, when the endpoint is not found in the configuration file. Further, the CAPIF module is configured to register the service API and the endpoint associated with the service API with the system.
[0020] In an embodiment, the CAPIF module is further configured to determine the API provider as valid upon detecting presence of the endpoint in the configuration file. Further, the CAPIF module is configured to verify a plurality of credentials of the API provider to allow the API provider to register a plurality of service APIs with the system.
[0021] In another aspect of the present invention, a non-transitory computer-readable medium having stored thereon computer-readable instructions that, when executed by a processor, cause the processor to receive a request for registering the service API from a user equipment, wherein the request comprises a plurality of details of an endpoint of the service API and configuration parameters associated with the service API; search for the endpoint within a configuration file based on the plurality of details and the configuration parameters; and forward the request to an associated CAPIF module, when the endpoint is found in the configuration file.
[0022] Other features and aspects of this invention will be apparent from the following description and the accompanying drawings. The features and advantages described in this summary and in the following detailed description are not all-inclusive, and particularly, many additional features and advantages will be apparent to one of ordinary skill in the relevant art, in view of the drawings, specification, and claims hereof. Moreover, it should be noted that the language used in the specification has been principally selected for readability and instructional purposes and may not have been selected to delineate or circumscribe the inventive subject matter, resort to the claims being necessary to determine such inventive subject matter.

BRIEF DESCRIPTION OF THE DRAWINGS
[0023] The accompanying drawings, which are incorporated herein, and constitute a part of this disclosure, illustrate exemplary embodiments of the disclosed methods and systems in which like reference numerals refer to the same parts throughout the different drawings. Components in the drawings are not necessarily to scale, emphasis instead being placed upon clearly illustrating the principles of the present disclosure. Some drawings may indicate the components using block diagrams and may not represent the internal circuitry of each component. It will be appreciated by those skilled in the art that disclosure of such drawings includes disclosure of electrical components, electronic components or circuitry commonly used to implement such components.
[0024] FIG. 1 is an exemplary block diagram of an environment for managing endpoint for the service API received from an API provider, according to various embodiments of the present disclosure.
[0025] FIG. 2 is a block diagram of a system of FIG. 1, according to various embodiments of the present disclosure.
[0026] FIG. 3 is an example schematic representation of the system of FIG. 1 in which various entities operations are explained, according to various embodiments of the present system.
[0027] FIG. 4 depicts an example flow chart of publishing a service API within the system, according to one or more embodiments of the present invention.
[0028] FIG. 5 represents an example flow chart of unpublishing the service API within the system, according to one or more embodiments of the present invention.
[0029] FIG. 6 illustrates an example method flow for dynamic endpoint management within the API ecosystem, according to one or more embodiments of the present invention.
[0030] FIG. 7 shows a flow chart illustrating a method for managing endpoint for a service API received from an API provider, according to various embodiments of the present disclosure.
[0031] Further, skilled artisans will appreciate that elements in the drawings are illustrated for simplicity and may not have been necessarily been drawn to scale. For example, the flow charts illustrate the method in terms of the most prominent steps involved to help to improve understanding of aspects of the present invention. Furthermore, in terms of the construction of the device, one or more components of the device may have been represented in the drawings by conventional symbols, and the drawings may show only those specific details that are pertinent to understanding the embodiments of the present invention so as not to obscure the drawings with details that will be readily apparent to those of ordinary skill in the art having benefit of the description herein.
[0032] The foregoing shall be more apparent from the following detailed description of the invention.

DETAILED DESCRIPTION OF THE INVENTION
[0033] Some embodiments of the present disclosure, illustrating all its features, will now be discussed in detail. It must also be noted that as used herein and in the appended claims, the singular forms "a", "an" and "the" include plural references unless the context clearly dictates otherwise.
[0034] Various modifications to the embodiment will be readily apparent to those skilled in the art and the generic principles herein may be applied to other embodiments. However, one of ordinary skill in the art will readily recognize that the present disclosure including the definitions listed here below are not intended to be limited to the embodiments illustrated but is to be accorded the widest scope consistent with the principles and features described herein.
[0035] A person of ordinary skill in the art will readily ascertain that the illustrated steps detailed in the figures and here below are set out to explain the exemplary embodiments shown, and it should be anticipated that ongoing technological development will change the manner in which particular functions are performed. These examples are presented herein for purposes of illustration, and not limitation. Further, the boundaries of the functional building blocks have been arbitrarily defined herein for the convenience of the description. Alternative boundaries can be defined so long as the specified functions and relationships thereof are appropriately performed. Alternatives (including equivalents, extensions, variations, deviations, etc., of those described herein) will be apparent to persons skilled in the relevant art(s) based on the teachings contained herein. Such alternatives fall within the scope and spirit of the disclosed embodiments.
[0036] Various embodiments of the invention provide a method of managing endpoint for a service API received from an API provider. The end points refer to specific Uniform Resource Locators (URLs) or Uniform Resource Identifiers (URIs) that client applications use to interact with different functionalities or resources offered by the API. The method includes receiving, by one or more processors, a request for registering the service API from a user equipment. The request includes a plurality of service API endpoint details and configuration parameters associated with the service API. Further, the method includes searching, by the one or more processors, for the endpoint within a configuration file based on the plurality of service API endpoint details and the configuration parameters. Further, the method includes forwarding, by the one or more processors, the request to a CAPIF module, when the endpoint is found in the configuration file.
[0037] The current invention addresses the limitations of traditional static endpoint configuration by introducing a dynamic endpoint management system for API providers. The proposed system enables runtime addition and deletion of endpoints, eliminating the need for program termination and manual configuration changes. The system provides a Command Line Interface (CLI) and an Interface (e.g., user interface (UI) or the like) to facilitate convenient and real-time configuration modifications.
[0038] By allowing dynamic control of API publishing function endpoints, the proposed system and method offers API providers the ability to respond promptly to changing consumer needs and requirements. This eliminates the arduous process of modifying static files and restarting the program. The API providers can now make configuration changes on-the-fly by simply modifying the configuration file via the CLI or UI.
[0039] The proposed system optimizes the routing of requests within the ecosystem, enabling seamless registration of API exposing functions with the CAPIF (Common API Function) core function. Dynamic endpoint management ensures that even if endpoint details are deleted or functional requirements change, the registration process remains unaffected. Overall, this invention revolutionizes API endpoint management, empowering API providers with flexibility, scalability, and efficient runtime configuration changes. It eliminates the previously hectic and time-consuming process of static endpoint management, enhancing the agility and adaptability of API ecosystems.
[0040] The proposed system allows runtime addition and deletion of endpoints without disrupting the application. The system offers the CLI and the interface for convenient configuration changes. Advantages include reduced development time, increased scalability, and the ability to change configurations at runtime. By mapping endpoints in an Edge Load Balancer (ELB) (or load balancer) and the CAPIF Core Function, the system optimizes traffic routing, ensuring seamless registration and efficient communication between API exposing functions. The invention empowers API providers to promptly respond to consumer needs, easily customize endpoints, and enhance the overall agility and performance of the API ecosystem
[0041] FIG. 1 illustrates an exemplary block diagram of an environment (100) to manage endpoint for the service API received from an API provider (402) (as shown in FIG. 4), according to various embodiments of the present disclosure. The environment (100) comprises a plurality of user equipment’s (UEs) 102-1, 102-2, ……,102-n. The at least one UE (102-n) from the plurality of the UEs (102-1, 102-2, ……102-n) is configured to connect to a system (108) via the communication network (106). Hereafter, label for the plurality of UEs or one or more UEs is 102.
[0042] In accordance with yet another aspect of the exemplary embodiment, the plurality of UEs (102) may be a wireless device or a communication device that may be a part of the system (108). The wireless device or the UE (102) may include, but are not limited to, a handheld wireless communication device (e.g., a mobile phone, a smart phone, a phablet device, and so on), a wearable computer device (e.g., a head-mounted display computer device, a head-mounted camera device, a wristwatch computer device, and so on), a laptop computer, a tablet computer, or another type of portable computer, a media playing device, a portable gaming system, and/or any other type of computer device with wireless communication or VoIP capabilities. In an embodiment, the UEs may include, but are not limited to, any electrical, electronic, electro-mechanical or an equipment or a combination of one or more of the above devices such as virtual reality (VR) devices, augmented reality (AR) devices, laptop, a general-purpose computer, desktop, personal digital assistant, tablet computer, mainframe computer, or any other computing device, wherein the computing device may include one or more in-built or externally coupled accessories including, but not limited to, a visual aid device such as camera, audio aid, a microphone, a keyboard, input devices (or input unit) for receiving input from a user such as touch pad, touch enabled screen, electronic pen and the like. It may be appreciated that the UEs may not be restricted to the mentioned devices and various other devices may be used. A person skilled in the art will appreciate that the plurality of UEs (102) may include a fixed landline, a landline with assigned extension within the communication network (106).
[0043] The plurality of UEs (102) may comprise a memory such as a volatile memory (e.g., RAM), a non-volatile memory (e.g., disk memory, FLASH memory, EPROMs, etc.), an unalterable memory, and/or other types of memory. In one implementation, the memory might be configured or designed to store data. The data may pertain to attributes and access rights specifically defined for the plurality of UEs (102). The UE (102) may be accessed by the user, to receive the requests related to an order determined by the system (108). The communication network (106), may use one or more communication interfaces/protocols such as, for example, Voice Over Internet Protocol (VoIP), 802.11 (Wi-Fi), 802.15 (including Bluetooth™), 802.16 (Wi-Max), 802.22, Cellular standards such as Code Division Multiple Access (CDMA), CDMA2000, Wideband CDMA (WCDMA), Radio Frequency Identification (e.g., RFID), Infrared, laser, Near Field Magnetics, etc.
[0044] The system (108) is communicatively coupled to a server (104) via the communication network (106). The server (104) can be, for example, but not limited to a standalone server, a server blade, a server rack, an application server, a bank of servers, a business telephony application server (BTAS), a server farm, a cloud server, an edge server, home server, a virtualized server, one or more processors executing code to function as a server, or the like. In an implementation, the server (104) may operate at various entities or a single entity (include, but is not limited to, a vendor side, a service provider side, a network operator side, a company side, an organization side, a university side, a lab facility side, a business enterprise side, a defence facility side, or any other facility) that provides service.
[0045] The communication network (106) includes, by way of example but not limitation, one or more of a wireless network, a wired network, an internet, an intranet, a public network, a private network, a packet-switched network, a circuit-switched network, an ad hoc network, an infrastructure network, a Public-Switched Telephone Network (PSTN), a cable network, a cellular network, a satellite network, a fiber optic network, or some combination thereof. The communication network (106) may include, but is not limited to, a Third Generation (3G), a Fourth Generation (4G), a Fifth Generation (5G), a Sixth Generation (6G), a New Radio (NR), a Narrow Band Internet of Things (NB-IoT), an Open Radio Access Network (O-RAN), and the like.
[0046] The communication network (106) may also include, by way of example but not limitation, at least a portion of one or more networks having one or more nodes that transmit, receive, forward, generate, buffer, store, route, switch, process, or a combination thereof, etc. one or more messages, packets, signals, waves, voltage or current levels, some combination thereof, or so forth. The communication network (106) may also include, by way of example but not limitation, one or more of a wireless network, a wired network, an internet, an intranet, a public network, a private network, a packet-switched network, a circuit-switched network, an ad hoc network, an infrastructure network, a Public-Switched Telephone Network (PSTN), a cable network, a cellular network, a satellite network, a fiber optic network, a VOIP or some combination thereof.
[0047] One or more network elements can be, for example, but not limited to a base station that is located in the fixed or stationary part of the communication network (106). The base station may correspond to a remote radio head, a transmission point, an access point or access node, a macro cell, a small cell, a micro cell, a femto cell, a metro cell. The base station enables transmission of radio signals to the UE or mobile transceiver. Such a radio signal may comply with radio signals as, for example, standardized by a 3GPP or, generally, in line with one or more of the above listed systems. Thus, a base station may correspond to a NodeB, an eNodeB, a Base Transceiver Station (BTS), an access point, a remote radio head, a transmission point, which may be further divided into a remote unit and a central unit.
[0048] 3GPP: The term “3GPP” is a 3rd Generation Partnership Project and is a collaborative project between a group of telecommunications associations with the initial goal of developing globally applicable specifications for Third Generation (3G) mobile systems. The 3GPP specifications cover cellular telecommunications technologies, including radio access, core network, and service capabilities, which provide a complete system description for mobile telecommunications. The 3GPP specifications also provide hooks for non-radio access to the core network, and for networking with non-3GPP networks.
[0049] The system (108) may include one or more processors (202) coupled with a memory (204), wherein the memory (204) may store instructions which when executed by the one or more processors (202) may cause the system (108) executing requests in the communication network (106) or the server (104). An exemplary representation of the system (108) for such purpose, in accordance with embodiments of the present disclosure, is shown in FIG. 2 as system (108). In an embodiment, the system (108) may include one or more processor(s) (202). The one or more processor(s) (202) may be implemented as one or more microprocessors, microcomputers, microcontrollers, edge or fog microcontrollers, digital signal processors, central processing units, logic circuitries, and/or any devices that process data based on operational instructions. Among other capabilities, the one or more processor(s) (202) may be configured to fetch and execute computer-readable instructions stored in the memory (204) of the system (108). The memory (204) may be configured to store one or more computer-readable instructions or routines in a non-transitory computer readable storage medium, which may be fetched and executed to create or share data packets over a network service.
[0050] The environment (100) further includes the system (108) communicably coupled to the remote server (104) and each UE of the plurality of UEs (102) via the communication network (106). The remote server (104) is configured to execute the requests in the communication network (106).
[0051] The system (108) is adapted to be embedded within the remote server (104) or is embedded as the individual entity. The system (108) is designed to provide a centralized and unified view of data and facilitate efficient business operations. The system (108) is authorized to access to update/create/delete one or more parameters of their relationship between the requests for a workflow associated with the service API, which gets reflected in real-time independent of the complexity of network.
[0052] In another embodiment, the system (108) may include an enterprise provisioning server (for example), which may connect with the remote server (104). The enterprise provisioning server provides flexibility for enterprises, ecommerce entities, finance entities to update/create/delete information related to the requests in real time as per their business needs. A user with administrator rights can access and retrieve the requests for the workflow and perform real-time analysis in the system (108).
[0053] The system (108) may include, by way of example but not limitation, one or more of a standalone server, a server blade, a server rack, a bank of servers, a business telephony application server (BTAS), 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. In an implementation, system (108) may operate at various entities or single entity (for example include, but is not limited to, a vendor side, service provider side, a network operator side, a company side, an organization side, a university side, a lab facility side, a business enterprise side, ecommerce side, finance side, a defence facility side, or any other facility) that provides service.
[0054] However, for the purpose of description, the system (108) is described as an integral part of the remote server (104), without deviating from the scope of the present disclosure. Operational and construction features of the system (108) will be explained in detail with respect to the following figures.
[0055] FIG. 2 illustrates a block diagram of the system (108) provided to manage endpoint for the service API received from the API provider (402), according to one or more embodiments of the present invention. As per the illustrated embodiment, the system (108) includes the one or more processors (202), the memory (204), an interface (206) (e.g., input/output interface unit), a display (208), an input unit (210), an API database (or database) (214) and a CLI (222). Further the system (108) may comprise one or more processors (202). The one or more processors (202), hereinafter referred to as the processor (202) may be implemented as one or more microprocessors, microcomputers, microcontrollers, digital signal processors, central processing units, state machines, logic circuitries, single board computers, and/or any devices that manipulate signals based on operational instructions. As per the illustrated embodiment, the system (108) includes one processor. However, it is to be noted that the system (108) may include multiple processors as per the requirement and without deviating from the scope of the present disclosure.
[0056] The information related to the request may be provided or stored in the memory (204) of the system (108). Among other capabilities, the processor (202) is configured to fetch and execute computer-readable instructions stored in the memory (204). The memory (204) may be configured to store one or more computer-readable instructions or routines in a non-transitory computer-readable storage medium, which may be fetched and executed to create or share data packets over a network service. The memory (204) may include any non-transitory storage device including, for example, volatile memory such as RAM, or non-volatile memory such as disk memory, EPROMs, FLASH memory, unalterable memory, and the like.
[0057] The memory (204) may comprise any non-transitory storage device including, for example, volatile memory such as Random-Access Memory (RAM), or non-volatile memory such as Electrically Erasable Programmable Read-only Memory (EPROM), flash memory, and the like. In an embodiment, the system (108) may include an interface(s). The interface(s) may comprise a variety of interfaces, for example, interfaces for data input and output devices, referred to as input/output (I/O) devices, storage devices, and the like. The interface(s) may facilitate communication for the system. The interface(s) may also provide a communication pathway for one or more components of the system. Examples of such components include, but are not limited to, processing unit/engine(s) and a database. The processing unit/engine(s) may be implemented as a combination of hardware and programming (for example, programmable instructions) to implement one or more functionalities of the processing engine(s).
[0058] The information related to the requests may further be configured to render on the interface (e.g., user interface or the like) (206). The interface (206) may include functionality similar to at least a portion of functionality implemented by one or more computer system interfaces such as those described herein and/or generally known to one having ordinary skill in the art. The interface (206) may be rendered on the display (208), implemented using Liquid Crystal Display (LCD) display technology, Organic Light-Emitting Diode (OLED) display technology, and/or other types of conventional display technology. The display (208) may be integrated within the system (108) or connected externally. Further the input unit (210) may include, but not limited to, keyboard, buttons, scroll wheels, cursors, touchscreen sensors, audio command interfaces, magnetic strip reader, optical scanner, etc.
[0059] The API database (214) may be communicably connected to the processor (202) and the memory (204). The API database (214) may be configured to store and retrieve the request pertaining to features, or services or workflow of the system (108), access rights, attributes, approved list, and authentication data provided by an administrator. Further the remote server (104) may allow the system (108) to update/create/delete one or more parameters of their information related to the request, which provides flexibility to roll out multiple variants of the request as per business needs. In another embodiment, the API database (214) may be outside the system (108) and communicated through a wired medium and wireless medium.
[0060] Further, the processor (202), in an embodiment, may be implemented as a combination of hardware and programming (for example, programmable instructions) to implement one or more functionalities of the processor (202). In the examples described herein, such combinations of hardware and programming may be implemented in several different ways. For example, the programming for the processor (202) may be processor-executable instructions stored on a non-transitory machine-readable storage medium and the hardware for the processor (202) may comprise a processing resource (for example, one or more processors), to execute such instructions. In the present examples, the memory (204) may store instructions that, when executed by the processing resource, implement the processor (202). In such examples, the system (108) may comprise the memory (204) storing the instructions and the processing resource to execute the instructions, or the memory (204) may be separate but accessible to the system (108) and the processing resource. In other examples, the processor (202) may be implemented by an electronic circuitry.
[0061] In order for the system (108) to manage endpoint for the service API received from the API provider (402), the processor (202) includes a load balancer (216), the CAPIF module (218) and an Identity and Access Management (IAM) module (220). The load balancer (216), the CAPIF module (218) and an IAM module (220) may be implemented as a combination of hardware and programming (for example, programmable instructions) to implement one or more functionalities of the processor (202). In the examples described herein, such combinations of hardware and programming may be implemented in several different ways. For example, the programming for the processor (202) may be processor-executable instructions stored on a non-transitory machine-readable storage medium and the hardware for the processor (202) may comprise a processing resource (for example, one or more processors), to execute such instructions. In the present examples, the memory (204) may store instructions that, when executed by the processing resource, implement the processor. In such examples, the system (108) may comprise the memory (204) storing the instructions and the processing resource to execute the instructions, or the memory (204) may be separate but accessible to the system (108) and the processing resource. In other examples, the processor (202) may be implemented by the electronic circuitry.
[0062] In order for the system (108) to manage endpoint for the service API received from the API provider (402), the load balancer (216), the CAPIF module (218) and the IAM module (220) are communicably coupled to each other. In an example embodiment, the load balancer (216) receives a request for registering a service API from a UE. The request includes a plurality of service API endpoint details and configuration parameters associated with the service API. The service API endpoint details typically refer to the specific information or metadata associated with each endpoint in the service API provided by the API provider. The service API endpoint details can be, for example, but not limited to an endpoint URL, a request parameter, a request header, a response format and an error handling information. The configuration parameter in the context of the service API provided by the API provider refer to specific settings or options that can be customized or configured by developers or users of the API. The configuration parameter can be, for example, but not limited to authentication credentials, logging levels, performance tuning information, security settings, logging and monitoring or the like.
[0063] Further, the load balancer (216) searches for the endpoint within a configuration file based on the plurality of service API endpoint details and the configuration parameters. For example, the configuration file can be in JSON or XML format, specifying the endpoints and their associated functions. The API provider (402) can easily modify the configuration file to accommodate changing consumer needs or adjust service offerings Further, the load balancer (216) forwards the request to the CAPIF module (218), when the endpoint is found in the configuration file. The CAPIF module (218) receives the request from the load balancer (216) when the endpoint is found in the configuration file.
[0064] FIG. 2 particularly illustrates the interaction between the interface (206) or the CLI (222) and the system components. In one implementation, the UI (206) and the CLI (222) serve as the interfaces through which API Exposing Functions (AEFs) interact with the system (108). The interface (206) and the CLI (222) allow the users to send registration requests and modify endpoint configurations conveniently. The interface (206) can be a web-based interface, while operating the command-line interface (CLI) (222).
[0065] In accordance with the implementation, the API Exposing Function (AEF) registration request is sent to the load balancer (216) from the interface (206) or the CLI (222). The AEF registration request can be an API registration request. The AEFs are responsible for providing the service APIs and acting as an entry point for service communication within the API ecosystem. They authenticate API invokers, validate authorizations, and log Service API invocations. Examples of AEFs include web services, microservices, or serverless functions.
[0066] According to the implementation, the load balancer (216) component is configured for routing the requests within the system (108). The load balancer (216) receives registration requests from the AEFs and searches for the associated endpoints and configuration files included in the registration requests. The load balancer (216) is configured with rules and policies to determine the appropriate destination for each request.
[0067] In accordance with the implementation, the endpoint configuration consists of a set of rules and mappings that define how requests are routed within the system (108). It associates specific endpoints with corresponding API functions or services. The configuration can be stored in a file or the database (214) and is dynamically updated based on the registration requests received. For example, the configuration file can be in JSON or XML format, specifying the endpoints and their associated functions.
[0068] In accordance with the implementation, dynamic endpoint update functionality is configured for real-time addition and deletion of endpoints. When the registration request is received, the load balancer (216) checks if the requested endpoint is already defined in the configuration. If found, the request is directly forwarded to the corresponding CAPIF module (218). If not found, the load balancer (216) dynamically updates the endpoint configuration to include the new endpoint and proceeds with the request forwarding.
[0069] In accordance with the implementation, the CAPIF module (218) serves as a core component configured for processing the registration requests and handling API invocations within the API ecosystem. It receives forwarded requests from the load balancer (216) and verifies the authenticity of an API consumer by sending an authentication request to the IAM module (220). The CAPIF module (218) is implemented as a server or a cluster of servers that execute the necessary logic and business rules.
[0070] According to the implementation, the IAM module (220) is configured for authenticating the authentication requests coming from the CAPIF module (218) and authorizing the API consumers as requested. It verifies the credentials provided in the registration request and performs access control checks. The IAM module (220) can be implemented using standard authentication protocols like OAuth, OpenID Connect, or custom authentication mechanisms.
[0071] Overall, FIG. 2 represents the flow and interaction between different components in the dynamic endpoint management system, showcasing how UI/CLI (222), the AEFs, the load balancer (216), the CAPIF module (218), and the IAM module (220) work together to enable runtime addition and deletion of endpoints while ensuring secure authentication and registration of API providers.
[0072] FIG. 3 is an example schematic representation of the system (300) of FIG. 1 in which various entities operations are explained, according to various embodiments of the present system. It is to be noted that the embodiment with respect to FIG. 3 will be explained with respect to the first UE (102-1) and the system (108) for the purpose of description and illustration and should nowhere be construed as limited to the scope of the present disclosure.
[0073] As mentioned earlier, the first UE (102-1) includes one or more primary processors (305) communicably coupled to the one or more processors (202) of the system (108). The one or more primary processors (305) are coupled with a memory (310) storing instructions which are executed by the one or more primary processors (305). Execution of the stored instructions by the one or more primary processors (305) enables the UE (102-1). The execution of the stored instructions by the one or more primary processors (305) further enables the UE (102-1) to execute the requests in the communication network (106).
[0074] As mentioned earlier, the one or more processors (202) is configured to transmit a response content related to the request to the UE (102-1). More specifically, the one or more processors (202) of the system (108) is configured to transmit the response content to at least one of the UE (102-1). A kernel (315) is a core component serving as the primary interface between hardware components of the UE (102-1) and the system (108). The kernel (315) is configured to provide the plurality of response contents hosted on the system (108) to access resources available in the communication network (106). The resources include one of a Central Processing Unit (CPU), memory components such as Random Access Memory (RAM) and Read Only Memory (ROM).
[0075] As per the illustrated embodiment, the system (108) includes the one or more processors (202), the memory (204), the interface (206), the display (208), and the input unit (210). The operations and functions of the one or more processors (202), the memory (204), the interface (206), the display (208), and the input unit (210) are already explained in FIG. 2. For the sake of brevity, we are not explaining the same operations (or repeated information) in the patent disclosure. Further, the processor (202) includes the load balancer (216), the CAPIF module (218) and the IAM module (220). The operations and functions of the load balancer (216), the CAPIF module (218) and the IAM module (220) are already explained in FIG. 2. For the sake of brevity, we are not explaining the same operations (or repeated information) in the patent disclosure.
[0076] FIG. 4 depicts an example flow chart (400) of publishing a service API within the system (108). At step 1, the API publishing function module (or API provider (402)) initiates a service API publish request, which is sent to the CAPIF module (218). At step 2, upon receiving the request, the CAPIF module (218) stores the API information and ensures its availability for subsequent invocations by other components. At step 3, the CAPIF module (218) sends the service API publish response to the API provider (402).
[0077] FIG. 5 represents an example flow chart (500) of unpublishing a service API within the system (500). At step 1, the API Publishing Function (or API provider (402)) sends a service API unpublish request to the CAPIF module (218), indicating the API that needs to be removed. At step 2 and step 3, the CAPIF module (218) processes the request, removes the corresponding API information, and provides a service API unpublish response, confirming the successful removal.
[0078] FIG. 6 illustrates the example method flow (600) for dynamic endpoint management within the API ecosystem.
[0079] At step 602, the registration request is received through the interface (206) or the CLI (222), which serves as the interface for API providers to interact with the system (108). The AEF initiates the registration process to expose its Service APIs and communicate with the API ecosystem. The interface (206)/CLI (222) allows the API provider to input the desired endpoint details and configuration for their service API.
[0080] At step 604, the load balancer (216) receives the registration request and searches for the associated endpoint and configuration in the configuration file. It checks if the requested endpoint is already defined in the configuration.
[0081] At step 606, if the requested endpoint is found in the configuration, the registration request is forwarded to the appropriate CAPIF module (218). However, if the requested endpoint is not found, the load balancer (216) dynamically updates the endpoint configuration to include the new endpoint. According to the implementation, the CAPIF module (218) receives the forwarded registration request and initiates the authentication process. It sends an authentication request to the IAM module (220) to validate the authenticity of the API consumer.
[0082] At step 608, the IAM module (220) verifies the consumer's credentials and performs authorization checks. It ensures that the API consumer has the necessary permissions and access rights to register their Service API with the CAPIF module (218).
[0083] At step 610, if the consumer's authentication and authorization are successful, the CAPIF module (218) allows the AEF to complete the registration process. The AEF becomes an active participant within the API ecosystem, providing its Service APIs for consumption by other components or external consumers.
[0084] This method enables runtime addition and deletion of endpoints in the API ecosystem. It streamlines the process of registering API Exposing Functions, allowing for dynamic control and management of API publishing function endpoints. By providing a flexible UI/CLI interface and leveraging the capabilities of the load balancer (216), the CAPIF module (218), and IAM module (220), the method ensures secure and efficient registration of API providers while accommodating changes to endpoint configurations in real-time.
[0085] The present embodiment offers following advantages:
[0086] Reduced Development Time: The current invention significantly reduces development time by enabling runtime addition and deletion of endpoint nodes. This eliminates the need to modify the code or terminate the program for making changes to the endpoint configuration. API providers can dynamically manage their endpoints, saving valuable development resources and accelerating time-to-market for new services and APIs.
[0087] Increased Scalability: The ability to dynamically add and remove endpoints at runtime enhances the scalability of the system. API providers can scale their infrastructure and handle increased traffic by adding new endpoints as needed. Conversely, they can remove underutilized or deprecated endpoints to optimize resource allocation. This dynamic scalability ensures efficient resource utilization and a seamless experience for API consumers.
[0088] Real-time Configuration Changes: The invention allows users to change endpoint configurations at runtime without the need to restart the program or modify the code. By leveraging the CLI (222) or the interface (206), the API providers (402) can easily modify the configuration file to accommodate changing consumer needs or adjust service offerings. This flexibility enables quick adaptation to evolving requirements and provides a seamless experience for API consumers.
[0089] Efficient Traffic Routing: The invention leverages the capability of mapping endpoints in the load balancer (216) and the CAPIF Core Function to facilitate efficient traffic routing. By dynamically managing endpoint configurations, the system ensures that incoming requests are seamlessly routed to the respective applications or services. This optimized traffic routing enhances performance, reduces latency, and improves overall system efficiency.
[0090] Easy Endpoint Customization: The invention simplifies the process of customizing endpoints during application runtime. If a consumer requires a new service or API, or wants to modify their existing endpoints, API providers can easily accommodate these changes without the need for code modifications. The configuration file can be updated through the CLI (222) or the interface (206), allowing for seamless customization of endpoints to meet consumer demands.
[0091] FIG. 7 is a flow chart (700) illustrating a method for managing endpoint for the service API received from the API provider (402), according to various embodiments of the present system.
[0092] At 702, the method includes receiving the request for registering the service API from the user equipment. The request includes the plurality of service API endpoint details and the configuration parameters associated with the service API. At 704, the method includes searching for the endpoint within the configuration file based on the plurality of service API endpoint details and the configuration parameters. At 706, the method includes forwarding the request to the CAPIF module (218), when the endpoint is found in the configuration file.
[0093] A person of ordinary skill in the art will readily ascertain that the illustrated embodiments and steps in description and drawings (FIGS. 1-7) are set out to explain the exemplary embodiments shown, and it should be anticipated that ongoing technological development will change the manner in which particular functions are performed. These examples are presented herein for purposes of illustration, and not limitation. Further, the boundaries of the functional building blocks have been arbitrarily defined herein for the convenience of the description. Alternative boundaries can be defined so long as the specified functions and relationships thereof are appropriately performed. Alternatives (including equivalents, extensions, variations, deviations, etc., of those described herein) will be apparent to persons skilled in the relevant art(s) based on the teachings contained herein. Such alternatives fall within the scope and spirit of the disclosed embodiments.
[0094] Method steps: A person of ordinary skill in the art will readily ascertain that the illustrated steps are set out to explain the exemplary embodiments shown, and it should be anticipated that ongoing technological development will change the manner in which particular functions are performed. These examples are presented herein for purposes of illustration, and not limitation. Further, the boundaries of the functional building blocks have been arbitrarily defined herein for the convenience of the description. Alternative boundaries can be defined so long as the specified functions and relationships thereof are appropriately performed. Alternatives (including equivalents, extensions, variations, deviations, etc., of those described herein) will be apparent to persons skilled in the relevant art(s) based on the teachings contained herein. Such alternatives fall within the scope and spirit of the disclosed embodiments.
[0095] The present invention offers multiple advantages over the prior art and the above listed are a few examples to emphasize on some of the advantageous features. The listed advantages are to be read in a non-limiting manner.

REFERENCE NUMERALS
[0096] Environment - 100
[0097] UEs– 102, 102-1-102-n
[0098] Server - 104
[0099] Communication network – 106
[00100] System – 108
[00101] Processor – 202
[00102] Memory – 204
[00103] Interface – 206
[00104] Display – 208
[00105] Input unit – 210
[00106] API Database – 214
[00107] Load balancer - 216
[00108] CAPIF module – 218
[00109] IAM module – 220
[00110] CLI - 222
[00111] System - 300
[00112] Primary processors -305
[00113] Memory– 310
[00114] Kernel– 315
[00115] API provider - 402

,CLAIMS:CLAIMS:
We Claim
1. A method of managing endpoint for a service Application Programming Interface (API) received from an API provider (402), wherein the method comprising the steps of:
receiving, by one or more processors (202), a request for registering the service API from a user equipment, wherein the request comprises a plurality of service API endpoint details and configuration parameters associated with the service API;
searching, by the one or more processors (202), for the endpoint within a configuration file based on the plurality of service API endpoint details and the configuration parameters; and
forwarding, by the one or more processors (202), the request to a Common API Framework (CAPIF) module (218), when the endpoint is found in the configuration file.

2. The method as claimed in claim 1, further comprising updating, by the one or more processors (202), the configuration file with the details of the endpoint and the configuration parameters, when the endpoint is not found in the configuration file.

3. The method as claimed in claim 2, wherein updating the configuration file with the plurality of details of the endpoint and the configuration parameters adds a new endpoint into a system (108) associated with the CAPIF module (218), wherein the system (108) manages a plurality of service APIs from a plurality of API providers.

4. The method as claimed in claim 1, wherein the configuration file is stored in an API database (214).

5. The method as claimed in claim 1, wherein the user equipment is associated with the API provider (402).

6. The method as claimed in claim 1, wherein upon detecting presence of the endpoint in the configuration file, the API provider (402) is determined to be valid, and a plurality of credentials of the API provider (402) is verified.

7. The method as claimed in claim 6, wherein the valid API provider (402) is allowed to register a plurality of service APIs with the CAPIF module (218).

8. The method as claimed in claim 1, wherein the request is received via one of a interface (UI) (206) and a command line interface (CLI) associated with the user equipment, and wherein one of the interface (206) and the CLI facilitate the user equipment to send one or more requests for modifying the plurality of details of the endpoint and the configuration parameters.

9. A system (108) for managing endpoint for a service Application Programming Interface (API) received from an API provider (402), wherein the system (108) comprises:
a load balancer (216) configured to:
receive a request for registering the service API from a user equipment, wherein the request comprises a plurality of service API endpoint details and configuration parameters associated with the service API;
search for the endpoint within a configuration file based on the plurality of service API endpoint details and the configuration parameters; and
forward the request to a Common API Framework (CAPIF) module (218), when the endpoint is found in the configuration file; and
the CAPIF module (218) is configured to:
receive the request from the load balancer (216) when the endpoint is found in the configuration file.

10. The system (108) as claimed in claim 9, wherein one of: an interface (UI) (206) and a command line interface (CLI) (216) associated with the user equipment (102) enables routing of the request to the load balancer (216), and wherein the load balancer (216) routes the request to the CAPIF module (218) when the endpoint is found in the configuration file.

11. The system (108) as claimed in claim 9, wherein one of: the interface (206) and the CLI (222) is configured to:
enable the user equipment of the API provider (402) to interact with one or more modules of the system (108);
facilitate the user equipment to send the request for registering the service API; and
facilitate the user equipment to send one or more requests for modifying the plurality of details of the endpoint and the configuration parameters.

12. The system (108) as claimed in claim 9, wherein the load balancer (216) is configured with a set of rules that determine a destination for each request.

13. The system (108) as claimed in claim 9, wherein the CAPIF module (218) is further configured to:
update the configuration file with the details of the endpoint and the configuration parameters, when the endpoint is not found in the configuration file.

14. The system (108) as claimed in claim 9, wherein the CAPIF module (218) is further configured to:
update the configuration file with the plurality of details of the endpoint and the configuration parameters, when the endpoint is not found in the configuration file; and
register the service API and the endpoint associated with the service API with the system (108).

15. The system (108) as claimed in claim 9, wherein the configuration file is stored in an API database (214).

16. The system (108) as claimed in claim 9, wherein the user equipment is associated with the API provider (402).

17. The system (108) as claimed in claim 9, wherein the CAPIF module (218) is further configured to:
determine the API provider (402) as valid upon detecting presence of the endpoint in the configuration file; and
verify a plurality of credentials of the API provider (402) to allow the API provider (402) to register a plurality of service APIs with the system (108).

18. The system (108) as claimed in claim 9, wherein the request is received via one of an interface (206) and a command line interface (CLI) (216) associated with the user equipment (102), and wherein one of the interface (206) and the CLI (222) are configured to facilitate the user equipment to send a request for modifying the plurality of details of the endpoint and the configuration parameters.

19. A User Equipment (UE) (102-1), comprising:
one or more primary processors (305) communicatively coupled to one or more processors (202) of a system (108), the one or more primary processors (305) coupled with a memory (310), wherein said memory (310) stores instructions which when executed by the one or more primary processors (305) causes the UE (102-1) to:
transmit, a request for registering the service API to the one or more processers (202);
wherein the one or more processors (202) is configured to perform the steps as claimed in claim 1.