Description:FORM 2

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

COMPLETE SPECIFICATION
(See Section 10 and Rule 13)

Title of invention:
SYSTEM AND METHOD FOR IDENTIFYING, ENHANCING, AND GENERATING MICROSERVICES APPLICATION PROGRAMMING INTERFACE (API) DESIGNS

Applicant:
Tata Consultancy Services Limited
A company Incorporated in India under the Companies Act, 1956
Having address:
Nirmal Building, 9th Floor,
Nariman Point, Mumbai 400021,
Maharashtra, India

The following specification particularly describes the invention and the manner in which it is to be performed.
TECHNICAL FIELD
[001] The disclosure herein generally relates to microservices application programming interface (API) designs, and, more particularly, to systems and methods for identifying, enhancing, and generating microservices application programming interface (API) designs.

BACKGROUND
[002] The tremendous growth in the microservices API (Application Programming Interface) based architecture adoption by majority of the industries in their diverse applications, may it be in cloud or on premise, customer facing or backend applications, has resulted in an enormous demand for the APIs. While some organizations have a well-structured and controlled API design and development through centralized API platform team, other organizations have a more autonomous structure, wherein the application development team builds the APIs to meet their application’s specific use case. In either case, consumers of the API must engage the API Application Development (AD) team to explain the business use cases, provide the requirement details, such as fields that they need from the system of records, have several rounds of meeting to clarify the expectation, and wait for the engagement formalities and assessment completion from AD team. This results in extensive delays for applications in an organization that are dependent on these microservices to get the data from a system of records. Also, the consuming application’s business analysts/specialist, ‘who are mostly business professional than technical’, must depend on the AD team members either from their application team or from the API platform team, to research and analyze the catalog of existing microservices APIs, if one exist in the organization, to understand the API design, business scenarios or use case that the API(s) caters to, business rules, if any that it implements, and the system of records from where it retrieves the data, so that a decision can be made on if application can re-use any existing API design as-is, enhance it, or create a new API design to meet their business requirement. This exercise/assessment requires in-depth understanding of the API contract (also referred to as design), its implementation, interfaces and integrations with other APIs and the system of records. Therefore, organizations and applications consuming APIs lack self-servicing capability and thus are unable to identify, enhance and/or creating new API designs.

SUMMARY
[003] Embodiments of the present disclosure present technological improvements as solutions to one or more of the above-mentioned technical problems recognized by the inventors in conventional systems.
[004] For example, in one aspect, there is provided a processor implemented method for identifying, enhancing, and/or generating microservices application programming interface (API) designs. The method comprises identifying, via one or more hardware processors, one or more touchpoints from a plurality of categories, wherein the one or more touchpoints is based on a selection by a user and are specific to one or more business requirements associated with the user; capturing and identifying, via one or more hardware processors, an intent of the user from the selected one or more touchpoints; iteratively processing, by using a machine learning (ML) model via the one or more hardware processors, the intent of the user based on a selection of one or more associated keywords and attributes that are queried in one or more metadata repositories, and one or more configuration files to obtain a fine-tuned intent pertaining to the user; processing the fine-tuned intent to render information from the one or more metadata repositories pertaining to the selected one or more touchpoints, wherein the rendered information maps to the fine-tuned intent of the user; processing the rendered information to obtain one or more candidate microservices Application Programming Interface (API) designs, wherein the one or more candidate microservices Application Programming Interface (API) designs are based on at least one of one or more structured data-based files; and registering at least one microservices API design amongst one or more candidate microservices Application Programming Interface (API) designs with an API platform, wherein the at least one microservices API design is registered with the API platform for provisioning of an integration interface for integration with one or more environments.
[005] In an embodiment, the registered microservices API design is specific to the one or more business requirements associated with the user.
[006] In an embodiment, the one or more candidate microservices Application Programming Interface (API) designs comprise at least one of a re-use microservice API design, an enhanced microservice API design, and a new microservices API design.
[007] In an embodiment, the one or more metadata repositories are queried to render the information based on an associated property file.
[008] In an embodiment, the one or more touchpoints comprise at least one of one or more system interface touchpoints, one or more API design functional touchpoints, and one or more API design journey touchpoints.
[009] In another aspect, there is provided a processor implemented system for identifying and generating microservices application programming interface (API) designs. The system comprises: a memory storing instructions; one or more communication interfaces; and one or more hardware processors coupled to the memory via the one or more communication interfaces, wherein the one or more hardware processors are configured by the instructions to: identify one or more touchpoints from a plurality of categories, wherein the one or more touchpoints is based on a selection by a user and are specific to one or more business requirements associated with the user; capture and identify an intent of the user from the selected one or more touchpoints; iteratively process, by using a machine learning (ML) model, the intent of the user based on a selection of one or more associated keywords and attributes that are queried in one or more metadata repositories, and one or more configuration files to obtain a fine-tuned intent pertaining to the user; process the fine-tuned intent to render information from the one or more metadata repositories pertaining to the selected one or more touchpoints, wherein the rendered information maps to the fine-tuned intent of the user; process the rendered information to obtain one or more candidate microservices Application Programming Interface (API) designs, wherein the one or more candidate microservices Application Programming Interface (API) designs are based on at least one of one or more structured data-based files; and register at least one microservices API design amongst one or more candidate microservices Application Programming Interface (API) designs with an API platform, wherein the at least one microservices API design is registered with the API platform for provisioning of an integration interface for integration with one or more environments.
[010] In an embodiment, the registered microservices API design is specific to the one or more business requirements associated with the user.
[011] In an embodiment, the one or more candidate microservices Application Programming Interface (API) designs comprise at least one of a re-use microservice API design, an enhanced microservice API design, and a new microservices API design.
[012] In an embodiment, the one or more metadata repositories are queried to render the information based on an associated property file.
[013] In an embodiment, the one or more touchpoints comprise at least one of one or more system interface touchpoints, one or more API design functional touchpoints, and one or more API design journey touchpoints.
[014] In yet another aspect, there are provided one or more non-transitory machine-readable information storage mediums comprising one or more instructions which when executed by one or more hardware processors cause identifying and generating microservices application programming interface (API) designs by identifying one or more touchpoints from a plurality of categories, wherein the one or more touchpoints is based on a selection by a user and are specific to one or more business requirements associated with the user; capturing and identifying an intent of the user from the selected one or more touchpoints; iteratively processing, by using a machine learning model, the intent of the user based on a selection of one or more associated keywords and attributes that are queried in one or more metadata repositories, and one or more configuration files to obtain a fine-tuned intent pertaining to the user; processing the fine-tuned intent to render information from the one or more metadata repositories pertaining to the selected one or more touchpoints, wherein the rendered information maps to the fine-tuned intent of the user; processing the rendered information to obtain one or more candidate microservices Application Programming Interface (API) designs, wherein the one or more candidate microservices Application Programming Interface (API) designs are based on at least one of one or more structured data-based files; and registering at least one microservices API design amongst one or more candidate microservices Application Programming Interface (API) designs with an API platform, wherein the at least one microservices API design is registered with the API platform for provisioning of an integration interface for integration with one or more environments.
[015] In an embodiment, the registered microservices API design is specific to the one or more business requirements associated with the user.
[016] In an embodiment, the one or more candidate microservices Application Programming Interface (API) designs comprise at least one of a re-use microservice API design, an enhanced microservice API design, and a new microservices API design.
[017] In an embodiment, the one or more metadata repositories are queried to render the information based on an associated property file.
[018] In an embodiment, the one or more touchpoints comprise at least one of one or more system interface touchpoints, one or more API design functional touchpoints, and one or more API design journey touchpoints.
[019] It is to be understood that both the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the invention, as claimed.

BRIEF DESCRIPTION OF THE DRAWINGS
[020] The accompanying drawings, which are incorporated in and constitute a part of this disclosure, illustrate exemplary embodiments and, together with the description, serve to explain the disclosed principles:
[021] FIG. 1 depicts an exemplary system for identifying, enhancing, and generating microservices application programming interface (API) designs, in accordance with an embodiment of the present disclosure.
[022] FIG. 2 depicts an exemplary flow chart illustrating a method for identifying, enhancing, and generating microservices application programming interface (API) designs, using the system of FIG. 1, in accordance with an embodiment of the present disclosure.
[023] FIG. 3 depicts a flow-chart illustrating steps involved in capturing and identifying an intent of the user and processing the intent of the user to obtain a fine-tuned intent, in accordance with an embodiment of the present disclosure.
[024] FIG. 4 depicts a flow-chart illustrating steps involved in processing the fine-tuned intent to render information, in accordance with an embodiment of the present disclosure.
[025] FIG. 5 depicts a flow-chart illustrating steps involved in processing the rendered information to obtain one or more candidate microservices Application Programming Interface (API) designs for review to determine re-use or enhance or start a journey of creating new API design, in accordance with an embodiment of the present disclosure.
[026] FIG. 6 depicts a flow-chart illustrating steps involved in registering at least one microservices API design amongst the one or more candidate microservices API designs with an API platform, in accordance with an embodiment of the present disclosure.

DETAILED DESCRIPTION OF EMBODIMENTS
[027] Exemplary embodiments are described with reference to the accompanying drawings. In the figures, the left-most digit(s) of a reference number identifies the figure in which the reference number first appears. Wherever convenient, the same reference numbers are used throughout the drawings to refer to the same or like parts. While examples and features of disclosed principles are described herein, modifications, adaptations, and other implementations are possible without departing from the scope of the disclosed embodiments.
[028] The traditional approach, followed by most organizations is that the business professionals place a request for the requirement to API Platform team providing details of their functionality and data expectation, the API Platform team then reviews requirement, interpret it to best of their skills, work on clarifications, researching existing APIs, finding data from system of records, checking if it is returned in the API, and then working on timeline to design and build the API. This approach is not only time consuming but also leads to potential gaps in delivering API design that may not completely satisfy the business requirement.
[029] It is obviously challenging to find API platform resources who are skilled in diverse business domain processes, API design frameworks, and organization’s system of records data model. Embodiments of the present disclosure handle and addresses these challenges by providing API self-servicing creation systems and methods that can learn and improve as it starts serving more professionals from organizations applications across domain offerings. The subject matter experts from the overall architecture layers can contribute to build the application components without the knowledge of the organization business processes or application functionalities. For example, a System of Record (SoR) layer builds the SoR Metadata Repository containing the fields exposed by SoR, that enables enhancing and updating the business names, definitions, and business use cases, and finally, the attribute definition can be put into by an API platform layer following industry and organization’s API design standards for each field that can be used for creating the API design.
[030] Referring now to the drawings, and more particularly to FIG. 1 through 6, where similar reference characters denote corresponding features consistently throughout the figures, there are shown preferred embodiments, and these embodiments are described in the context of the following exemplary system and/or method.
[031] FIG. 1 depicts an exemplary system 100 for identifying, enhancing, and generating microservices application programming interface (API) designs, in accordance with an embodiment of the present disclosure. In an embodiment, the system 100 includes one or more hardware processors 104, communication interface device(s) or input/output (I/O) interface(s) 106 (also referred as interface(s)), and one or more data storage devices or memory 102 operatively coupled to the one or more hardware processors 104. The one or more processors 104 may be one or more software processing components and/or hardware processors. In an embodiment, the hardware processors can be implemented as one or more microprocessors, microcomputers, microcontrollers, digital signal processors, central processing units, state machines, logic circuitries, and/or any devices that manipulate signals based on operational instructions. Among other capabilities, the processor(s) is/are configured to fetch and execute computer-readable instructions stored in the memory. In an embodiment, the system 100 can be implemented in a variety of computing systems, such as laptop computers, notebooks, hand-held devices (e.g., smartphones, tablet phones, mobile communication devices, and the like), workstations, mainframe computers, servers, a network cloud, and the like.
[032] The I/O interface device(s) 106 can include a variety of software and hardware interfaces, for example, a web interface, a graphical user interface, and the like and can facilitate multiple communications within a wide variety of networks (N/W) and protocol types, including wired networks, for example, LAN, cable, GPUs, etc., and wireless networks, such as WLAN, cellular, or satellite. In an embodiment, the I/O interface device(s) can include one or more ports for connecting a number of devices to one another or to another server.
[033] The memory 102 may include any computer-readable medium known in the art including, for example, volatile memory, such as static random-access memory (SRAM) and dynamic-random access memory (DRAM), and/or non-volatile memory, such as read only memory (ROM), erasable programmable ROM, flash memories, hard disks, optical disks, and magnetic tapes. In an embodiment, a database 108 is comprised in the memory 102, wherein the database 108 comprises information pertaining to one or more business requirements pertaining to various users and/or entities (e.g., organization(s), and the like). The database 108 further comprises identified intent comprised in the touchpoints associated with the users, wherein the touchpoints are identified based on an interaction with one or more user interface elements associated with a webpage (e.g., say internet website, host website that is configured to generate microservices API designs), chatbot application, and the like. The memory 102 further comprises (or may further comprise) information pertaining to input(s)/output(s) of each step performed by the systems and methods of the present disclosure. In other words, input(s) fed at each step and output(s) generated at each step are comprised in the memory 102 and can be utilized in further processing and analysis.
[034] FIG. 2, with reference to FIG. 1, depicts an exemplary flow chart illustrating a method for identifying, enhancing, and generating microservices application programming interface (API) designs, using the system 100 of FIG. 1, in accordance with an embodiment of the present disclosure. In an embodiment, the system(s) 100 comprises one or more data storage devices or the memory 102 operatively coupled to the one or more hardware processors 104 and is configured to store instructions for execution of steps of the method by the one or more processors 104. The steps of the method of the present disclosure will now be explained with reference to components of the system 100 of FIG. 1, and the flow diagram as depicted in FIG. 2. Although process steps, method steps, techniques or the like may be described in a sequential order, such processes, methods, and techniques may be configured to work in alternate orders. In other words, any sequence or order of steps that may be described does not necessarily indicate a requirement that the steps be performed in that order. The steps of processes described herein may be performed in any order practical. Further, some steps may be performed simultaneously.
[035] At step 202 of the method of the present disclosure, the one or more hardware processors 104 identify one or more touchpoints from a plurality of categories. The one or more touchpoints is based on a selection by a user and are specific to one or more business requirements associated with the user. The one or more touchpoints are identified based on one or more interactions of the user with the system 100. The user interacting with the system 100 in one scenario could for example, (i) professionals with diverse expertise, collaborating in delivering a functionality/feature specific to one or more products/services for internal and/or external customers, (ii) business professionals including, product/service supervisors, business analysts, product owners, scrum masters, subject matter experts, and so on, (iii) technical professionals such as system analysts, information technology specialists, architects, application developers, and so on, (iv) management professionals such as project managers, directors, project sponsor, etc. and the like. The one or more touchpoints comprise but are not limited to, one or more system interface touchpoints, one or more API design functional touchpoints, and one or more API design journey touchpoints.
[036] For one or more system interface touchpoints type, the system 100 may provide an artificial intelligence (AI) enabled prompt and navigation-based chat interface leveraging the generative AI capabilities, and/or a modern web hosted application interface to capture and identify the user intent. For instance, in one scenario, a prompt may be generated by the system 100 with a text field display “APIs exposing data from SoR3.” Upon selection of the above text field, the system may provide appropriate response and based on which intent of the user may be captured and identified. For example:
1. Below is the list of APIs exposing data from SOR3:
a. Retrieve Claims: /v1/claims
b. Retrieve Claim Procedures: /v1/claims/{id}/procedures
2. Please click on API to get the API design.
[037] Alternatively, in another scenario, the system 100 may provide various menu options such as API design discovery, API design enhancement, API design generation, manage metadata repositories, and manage API design subscriptions, and so on. These options help the system 100 to identify them as the one or more API design functional touchpoints. For example, the API design discovery option enables the user(s) to interact with the system 100 to discover an existing API design to determine if they can be re-used or enhanced to meet their functional requirements. The API design enhancement option enables the user(s) to interact with the system 100 to enhance an existing API design to add more attributes (or on some scenarios remove or modify existing attributes) to meet their functional requirements. The API design generation option enables the user(s) to interact with the system 100 to generate a new API design meeting their functional requirements on data and transaction (create, read, update, delete, and so on). The manage metadata repositories enables subject matter expert professionals to interact with the system 100 to perform transactions (create, update, and delete) on appropriate metadata repositories. The manage API design subscriptions enables the subject matter expert professionals to interact with the system 100 to manage their API design subscriptions, generate reports, etc.
[038] Likewise, the one or more API design journey touchpoints enable users in getting self-servicing in their journey on API design discovery, API design enhancement, API design generation, and managing the metadata repositories. The touchpoints are very unique and foundational in any microservices API design, irrespective of business function they are addressing (provided below):
1. System of records: expectations related to performing the data manipulation operations (C-Create, R-Read, U-Update, D-Delete) from/on the system of record(s) those host the data required by the consumer’s functionality/systems.
a. For example: APIs sourcing data from SoR1.
2. Entities: expectations around servicing the data manipulation operations (C-Create, R-Read, U-Update, D-Delete) for an entity or entities those are used in consumer’s (or user’s) functionality/feature.
a. Example: APIs sourcing claims data.
b. For information:
i. An entity is a resource or collection of data that exists independently and is part of an organization’s business function. In an organization’s business processes, it can be serviced and/or processed separately. For example, organization/group, employees/associates, claims, bills, payments, accounts/policies, customer/user/party, product, service, etc.
3. APIs: Requirements specific to the APIs that are already available in the API platform that can be either re-used as-is or enhanced to meet the functionality/feature’s objective.
a. This touchpoint is primarily used in scenarios where consumers are aware of existing APIs that they are either already using and want to enhance or want to re-use in the functionality. For example: Enhance /v1/customers API to add their Multi-Factor Authentication Preference (email or phone).
4. Business Use Cases: In this touchpoint, the consumers starts their journey by specifying their API design expectation to the system that is related to their business objective, so that system, after determining the intent, can either find an existing API design that meet their requirement or help generate an API design aligning the intent to metadata categories like system of records and/or entity/entities and/or data attributes, etc. For example: an API that retrieves all the accounts/policies of a customer using the customer’s identifier (e.g., say social security number).
5. Attributes: This touchpoint contains the list of all the available data elements from the available system of records.
a. This touchpoint is primarily used in API design enhancement and new API design generation scenarios where consumers are predominantly looking for adding new attributes to an existing API’s design or selecting attributes to include in new API’s design, while on some rare occasions may also be looking for removing or modifying attributes as per their functional requirement.
b. Example:
i. Enhance get-claims API to add payment method and overpayment indicator.
ii. Create search-claims API accepting person identifiers like employee identifier, government identifier, birth date, claim number and return the claim information containing claim number, claim status, claim received data, claim service date, claim end date, claim amount, claim paid date, payment method, and recipient.
6. Subscriptions: The consumer subscribed to API designs.
a. This touchpoint is primarily used in scenarios where consumers are looking for enhancement to an existing API’s design that they are already using or want to re-use it in the functionality.
b. Example: Enhance get-claims-subscription API to add payment method and overpayment indicator.
[039] At step 204 of the method of the present disclosure, the one or more hardware processors 104 capture and identify an intent of the user (also referred to as user intent) from the selected one or more touchpoints. When the user starts interacting with the system 100 various prompts are generated along with touchpoints as mentioned above. The response to these prompts may be in terms of text, audio, and the like from the user which are captured to identify the intent. The intent is captured with the help of navigation functions that are captured through the various touchpoints selected by the user. More specifically, the prompts include user input text (short or long) explaining their intent. The captured intent indicates a potential identifier, category, or type to identify metadata repository, to use (SoR, Entity, API, UC, etc.), potential API design and/or attribute definition.
[040] At step 206 of the method of the present disclosure, the one or more hardware processors 104 iteratively processing, by using a machine learning model (e.g., large language model (LLM), random forest, support vector machine (SVM), regression model, and so on), the intent of the user based on a selection of one or more associated keywords and attributes that are queried in one or more metadata repositories, and one or more configuration files to obtain a fine-tuned intent pertaining to the user. The prompt(s) and the captured/identified intent are fed to one or more model(s) such as generative AI/large language model that searches for keywords and/or attributes in the prompt for a match with one or more metadata repositories to obtain the actual intent which is also referred to as the fine-tuned intent pertaining to the user. It is to be understood by a person having ordinary skill in the art or person skilled in the art that for identifying or obtaining the actual intent or the fine-tuned intent pertaining to the user, the system 100 is configured with the above mentioned LLMs (Large Language Models) which is trained using historical data comprising metadata repositories associated with various application domains. The trained LLMs apply the learnings from the past and using the training obtain the fine-tuned intent of the user. FIG. 3, with reference to FIGS. 1 through 2, depicts a flow-chart illustrating steps involved in capturing and identifying an intent of the user, and processing the intent of the user to obtain a fine-tuned intent, in accordance with an embodiment of the present disclosure. Below Tables illustrate various schema structures. For instance, Table 1 illustrates most common elements in touchpoint metadata repository schema depicted below by way of non-construing examples:
Table 1

No. Keyword/Key Description
1 touchpoints An array of objects, where each object is a record related to a touchpoint that the system offers to its consumers.
1.1 identifier Unique identifier for a touchpoint. Ideally a custom number/alphanumeric value as enumeration code.
1.2 description Descriptive information about the touchpoint.
1.3 names An array of objects, where each object is a name given to the touchpoint. Mostly there will be only one record in this array object.
1.3.1 acronym Short form of the touchpoint name. Usually without spaces, only hyphen, & underscore like special characters.
1.3.2 fullForm Expanded, complete name of the touchpoint.
1.4 data An array of objects, where each object is a ‘Datum’ record indicating the data of sub-touchpoints.
1.4.1 category Category of the touchpoint. Category here can be referred as a sub-touchpoint/feature under a master touchpoint.
1.4.2 categoryDescription Definition/description of touchpoint category or feature.
1.4.3 categoryTypes An array of objects, where each object is a type of touchpoint category or type of a touchpoint feature.
It is to be noted that in case if category/feature has no sub types, then there will be one record specific to category/feature itself.
1.4.3.1 code A unique identifier specific to the touchpoint category/feature’s type.
1.4.3.2 value A value specific to the touchpoint category/feature’s type.
It is to be noted that sometimes the code and value may be same.
1.4.3.3 description Definition/description giving more information about the type of touchpoint category or feature.
It is to be noted that if ‘value’ is an acronym/short form, then description shall include the expanded form of the acronym along with other details.
1.4.3.4 userRoles An array of strings, where each string represents the role of a user/consumer accessing the touchpoint.
1.4.3.5 metadataFiles An array of objects, where each object is a reference to the metadata repository schema and examples files.
It is to be noted that there shall be at least one schema and example file for the data of a supported touchpoint category/feature type.
1.4.3.5.1 schemaIdentifier A unique identifier for the schema. It can be part of schema filename or an enumeration code.
1.4.3.5.2 schemaPath URI for retrieving and/or accessing the schema.
1.4.3.5.3 exampleFiles An array of objects, where each object is a scenario-based example implementing the schema.
1.4.3.5.3.1 identifier A unique identifier for the example based on scenario. It can be part of example filename or an enumeration code.
1.4.3.5.3.2 scenario Scenario description indicating what kind of data is included in the example file.
1.4.3.5.3.3 path URI for retrieving and/or accessing the example.
It is to be noted by a person having ordinary skill in the art or person skilled in the art that if any touchpoint requires different structure of schema, then either this schema can be extended, or similar new schema structure can be created.
[041] Table 2 illustrates most common elements in system of records (SoRs) metadata repository depicted below by way of non-construing examples:
Table 2

Ref. # Keyword/Key Description
1 systemOfRecords An array of objects, where each object is a record related to a source system for data.
1.1 identifier Unique identifier for a SoR. Ideally a custom number/alphanumeric value as enumeration code.
1.2 description Descriptive information about the SoR.
1.3 names An array of objects, where each object is a name given to the SoR. Mostly there will be only one record in this array object.
1.3.1 acronym Short form of the SoR. Usually without spaces and only hyphen or underscore like special characters.
1.3.2 fullForm Expanded, complete name of the SoR.
1.4 data An array of objects, where each object is a ‘Datum’ record indicating the data of an entity stored in the SoR.
1.4.1 category Category of the data stored in the SoR. Category here can be referred as an entity whose data is available in the SoR.
1.4.2 categoryDescription Definition/description of data category or entity.
1.4.3 categoryTypes An array of objects, where each object is a type of category or type of an entity.
It is to be noted that in case if category/entity has no types then there will be one record specific to category/entity itself.
1.4.3.1 code A unique identifier specific to the Category/Entity’s type.
1.4.3.2 value A value specific to the Category/Entity’s type.
It is to be noted that sometimes the code and value may be same.
1.4.3.3 description Definition/description giving more information about the type of category or entity.
It is to be noted that if ‘value’ is an acronym/short form, then description shall include the expanded form of the acronym along with other details.
1.4.3.4 metadataFiles An array of objects, where each object is a reference to the metadata repository schema and examples files.
It is to be noted that there shall be at least one schema and example file for the data of a category/entity type supported by SoR.
1.4.3.4.1 schemaIdentifier A unique identifier for the schema. It can be part of schema filename or an enumeration code.
1.4.3.4.2 schemaPath URI for retrieving and/or accessing the schema.
1.4.3.4.3 exampleFiles An array of objects, where each object is a scenario-based example implementing the schema.
1.4.3.4.3.1 identifier A unique identifier for the example based on scenario. It can be part of example filename or an enumeration code.
1.4.3.4.3.2 scenario Scenario description indicating what kind of data is included in the example file.
1.4.3.4.3.3 path URI for retrieving and/or accessing the example.

It is to be noted that if any SoR requires different structure of schema, then either this schema can be extended, or similar new schema structure can be created.
[042] Table 3 illustrates most common elements in entities metadata repository depicted below by way of non-construing examples:
Table 3

Ref. # Keyword/Key Description
1 entities An array of objects, where each object is a record related to an entity that encapsulates certain data attributes.
1.1 identifier Unique identifier for an entity. Ideally a custom number/alphanumeric value as enumeration code.
1.2 description Descriptive information about the entity.
1.3 names An array of objects, where each object is a name given to an entity. Mostly there will be only one record in this array object.
1.3.1 acronym Short form of an entity. Usually without spaces and only hyphen or underscore like special characters.
1.3.2 fullForm Expanded, complete name of an entity.
1.4 data An array of objects, where each object is a ‘Datum’ record indicating the details of an entity.
1.4.1 category Category of an entity that encapsulates or represents multiple types of entities. A category may be standalone entity as well.
1.4.2 categoryDescription Definition/description of entity’s category.
1.4.3 categoryTypes An array of objects, where each object is a type of an entity under a category.
It is to be noted that in case if entity category is standalone without any sub-entity/types, then there will be self-record of the category as a type of an entity.
1.4.3.1 code A unique identifier specific to the entity type.
1.4.3.2 value A value specific to the entity type.
It is to be noted that sometimes the code and value may be same.
1.4.3.3 description Definition/description giving more information about the type of category or entity.
It is to be noted that if ‘value’ is an acronym/short form, then description shall include the expanded form of the acronym along with other details.
1.4.3.4 systemOfRecords An array of strings, where each string represents the system of record storing the data for the type of category/entity.
1.4.3.5 metadataFiles An array of objects, where each object is a reference to the metadata repository schema and examples files.
It is to be noted that There shall be at least one schema and example file for the data of a category’s entity type.
1.4.3.5.1 schemaIdentifier A unique identifier for the schema. It can be part of schema filename or an enumeration code.
1.4.3.5.2 schemaPath URI for retrieving and/or accessing the schema.
1.4.3.5.3 exampleFiles An array of objects, where each object is a scenario-based example implementing the schema.
1.4.3.5.3.1 identifier A unique identifier for the example based on scenario. It can be part of example filename or an enumeration code.
1.4.3.5.3.2 scenario Scenario description indicating what kind of data is included in the example file.
1.4.3.5.3.3 path URI for retrieving and/or accessing the example.

It is to be noted that if any entity requires different structure of schema, then either this schema can be extended, or similar new schema structure can be created.
[043] Table 4 illustrates most common elements in API metadata repository depicted below by way of non-construing examples:
Table 4

Ref. # Keyword/Key Description
1 apis An array of objects, where each object is a record related to an API that performs specific operations on data.
1.1 identifier Unique identifier for an API. Ideally a custom number/alphanumeric value as enumeration code.
1.2 description Descriptive information about the entity.
1.3 names An array of objects, where each object is a name given to an entity. Mostly there will be only one record in this array object.
1.3.1 acronym Short form of an API. Usually without spaces and only hyphen or underscore like special characters.
1.3.2 fullForm Expanded, complete name of an API.
1.4 data An array of objects, where each object is a ‘Datum’ record indicating the details of an API.
1.4.1 category Category of the API’s data. It can be specification, reference to use cases where it is used, consumers, etc.
1.4.2 categoryDescription Definition/description of API data category.
1.4.3 categoryTypes An array of objects, where each object is a sub item or type under the category.
Example: For ‘specifications’ category, the types can be URL, HTTP Method, Protocol, Request Attributes, Response Attributes, Errors, etc.
1.4.3.1 code A unique identifier specific to the category’s type. Example: HTTPMETHOD
1.4.3.2 value A value specific to the category’s type. Example: GET.
It is to be noted that sometimes the code and value may be same.
1.4.3.3 description Definition/description giving more information about the type of category.
It is to be noted that if ‘value’ is an acronym/short form, then description shall include the expanded form of the acronym along with other details.
1.4.3.4 systemOfRecords An array of strings, where each string represents the system of record that is either source of data for the API or target for the data from the API.
It is to be noted that though it is related to the category types like request and response attributes, for category types those are not specific to data from SoR, it can be either empty or populated with the same source/target SoR(s) specified on request & response attributes.
1.4.3.5 metadataFiles An array of objects, where each object is a reference to the metadata repository schema and examples files.
It is to be noted that there shall be at least one schema and example file for data of API category types like ‘request attributes’, ‘response attributes’, and ‘errors’.
1.4.3.5.1 schemaIdentifier A unique identifier for the schema.
1.4.3.5.2 schemaPath URI for retrieving the schema.
1.4.3.5.3 exampleFiles An array of objects, where each object is a scenarios-based sample example.
1.4.3.5.3.1 identifier A unique identifier for the sample example based on scenario.
1.4.3.5.3.2 scenario Scenario description indicating what kind of data is addressed in the example.
1.4.3.5.3.3 path URI for retrieving the example.

It is to be noted that if any API requires different structure of schema, then either this schema can be extended, or similar new schema structure can be created.
[044] Table 5 illustrates most common elements in use case metadata repository depicted below by way of non-construing examples:
Table 5

Ref. # Keyword/Key Description
1 useCases An array of objects, where each object is a record related to a use case that is specific to a business functionality/feature.
It is to be noted that it is possible that a use case may be shared across multiple business functionalities/features having same objective.
1.1 identifier Unique identifier for a use case. Ideally a custom number/alphanumeric value as enumeration code.
1.2 description Descriptive information about the business use case.
1.3 names An array of objects, where each object is a name given to a use case in every business scenario it is referred.
It is to be noted that a use case may be named differently in different business scenarios even though they mean the same or their object is same.
1.3.1 acronym Short form of a use case. Usually without spaces and only hyphen or underscore like special characters. Spaces shall be replaced with either hyphen or underscore delimiter.
1.3.2 fullForm Expanded, complete name of a use case.
1.4 data An array of objects, where each object is a ‘Datum’ record indicating the details of the use case.
1.4.1 category Category of the use case.
It is to be noted that it is more dynamic in nature and related to the use case. If use case is based on an entity, then this can be sub-entity or type of entity or related entity’s type that adds categorization to the entity in the use case.
Example: In insurance industry, if use case is related to claim entity like ‘View list of Claims’, then category indicates, what product/coverage’s claim are expected.
1.4.2 categoryDescription Definition/description of the use case category.
1.4.3 categoryTypes An array of objects, where each object is a sub item or type under the category.
If category is one of the insurance products/coverages, then the type holds the value of any sub-products under that product or if not sub-products available, then it can be the same product mentioned in category.
Example: If category is DENTAL product, then a type could be PPO product or HMO product. Similarly, if category is DISABILITY product, then a type could be STD, LTD, etc.
1.4.3.1 code A unique identifier specific to the category’s type.
1.4.3.2 value A value specific to the category’s type.
It is to be noted that sometimes the code and value may be same.
1.4.3.3 description Definition/description giving more information about the type of category.
It is to be noted that if ‘value’ is an acronym/short form, then description shall include the expanded form of the acronym along with other details.
1.4.3.4 systemOfRecords An array of strings, where each string represents the system of record that is either source of data or target for the data for the category and type associated with the use case.
It is to be noted that it may be possible that there is no SoR for certain use cases or category and type.
1.4.3.5 metadataFiles An array of objects, where each object is a reference to the metadata repository schema and examples files.
It is to be noted that there shall be at least one schema and example file for data of use case category type.
1.4.3.5.1 schemaIdentifier A unique identifier for the schema.
1.4.3.5.2 schemaPath URI for retrieving the schema.
1.4.3.5.3 exampleFiles An array of objects, where each object is a scenarios-based sample example.
1.4.3.5.3.1 identifier A unique identifier for the sample example based on scenario.
1.4.3.5.3.2 scenario Scenario description indicating what kind of data is addressed in the example.
1.4.3.5.3.3 path URI for retrieving the example.
It is to be noted that if any use case requires different structure of schema, then either this schema can be extended, or similar new schema structure can be created.
[045] Table 6 illustrates most common elements in attributes metadata repository depicted below by way of non-construing examples:
Table 6

Ref. # Keyword/Key Description
1 attributes An array of objects, where each object is a record related to an attribute or a field.
It is to be noted that it is possible that an attribute may be sourced from multiple system of records and/or is associated with multiple entities or products or services.
1.1 identifier Unique identifier for an attribute. Ideally a custom number/alphanumeric value as enumeration code. Mostly it will be system generated identifier starting with one and incremented as more and more attributes are added.
1.2 description Descriptive information about an Attribute.
1.3 names An array of objects, where each object is represents a name for an attribute based on its source.
1.3.1 source Source for the name.
1.3.2 value Attribute names in the source. Note: in SoR, the attribute may exist in multiple tables or documents, etc.
1.4 systemOfRecords An array of strings, where each string represents the system of record that is either source of attribute or target for the attribute.
1.5 isSearchable A Boolean field indicating if attribute can be used for searching or retrieving other data attributes related to an entity or product.
1.6 associations An array of objects, where each object represents other associated data components or data categories/types.
1.6.1 type Type of data component associated with this attribute.
1.6.2 values An array of strings, where each string represents the associated data component’s type.

It is to be noted that if any attributes require different structure of schema, then either this schema can be extended, or similar new schema structure can be created.
[046] Table 7 illustrates most common elements in subscriptions metadata repository depicted below by way of non-construing examples:
Table 7

Ref. # Keyword/Key Description
1 subscriptions An array of objects, where each object is a record related to a subscription to an API design used by consumer.
1.1 identifier Unique identifier for a subscription. Ideally a custom number/alphanumeric value as enumeration code.
1.2 description Descriptive information about the subscription.
1.3 names An array of objects, where each object is a consumer name subscribed to an API design. There could be multiple names possible if subscription is used for multiple consumers.
1.3.1 acronym Short form of consumer who subscribed to use API design. Usually without spaces and only hyphen or underscore like special characters.
1.3.2 fullForm Expanded, complete consumer name.
1.4 data An array of objects, where each object is a ‘Datum’ record indicating the details of each consumer’s subscription.
1.4.1 category Category of the consumer’s subscription data. Each category can be specific to a consumer and an API specification/design that the consumer has subscribed.
Example: consumer1-get-claims-api-design-specification.
1.4.2 categoryDescription Definition/description of a category specific to consumer’s subscription.
1.4.3 categoryTypes An array of objects, where each object is a sub item or type under the category.
Example: For ‘consumer1-get-claims-api-design-specification’ category, the category types can be URL, HTTP Method, Protocol, Request Attributes, Response Attributes, Errors, etc.
1.4.3.1 code A unique identifier specific to the category’s type. Example: HTTPMETHOD
1.4.3.2 value A value specific to the category’s type. Example: GET.
It is to be noted that sometimes the code and value may be same.
1.4.3.3 description Definition/description giving more information about the type of category.
It is to be noted that if ‘value’ is an acronym/short form, then description shall include the expanded form of the acronym along with other details.
1.4.3.4 systemOfRecords An array of strings, where each string represents the system of record that is either source of data for or target for the data of the subscribed API design.
It is to be noted that though it is related to the category types like request and response attributes, for category types those are not specific to data from SoR, it can be either empty or populated with the same source/target SoR(s) specified on request & response attributes.
1.4.3.5 metadataFiles An array of objects, where each object is a reference to the metadata repository schema and examples files.
It is to be noted that there shall be at least one schema and example file for data of a subscribed API category types like ‘request attributes’, ‘response attributes’, and ‘errors.’
1.4.3.5.1 schemaIdentifier A unique identifier for the schema.
1.4.3.5.2 schemaPath URI for retrieving the schema.
1.4.3.5.3 exampleFiles An array of objects, where each object is a scenarios-based sample example.
1.4.3.5.3.1 identifier A unique identifier for the sample example based on scenario.
1.4.3.5.3.2 scenario Scenario description indicating what kind of data is addressed in the example.
1.4.3.5.3.3 path URI for retrieving the example.

[047] It is to be noted that if any subscription requires a different structure of schema, then either this schema can be extended, or similar new schema structure can be created.
[048] At step 208 of the method of the present disclosure, the one or more hardware processors 104 process the fine-tuned intent to render information (e.g., attributes) from the one or more metadata repositories pertaining to the selected one or more touchpoints. The rendered information maps to the fine-tuned intent of the user. The fine-tuned intent and its associated keywords and/or attributes such as one or more identified metadata repositories (MdR), an identifier, category, category type, etc. are processed by querying respective repositories wherein an API call is made to search for required information. For example, Mdr (metadata repository) is queried against metadata repository data wherein API call is made to get Mdr data. Mdr GET API is invoked to output the desired system of record. Similarly, respective API call is made to check for presence of associated keywords and/or attributes in corresponding repositories. For instance, for associated keywords and/or attributes, SoRs Master metadata repository (MMdR), entities MMdR, APIs MMdR, use cases MMdR, touchpoints MMdR, subscriptions MMdR, attributes MMdR may be queried by the appropriate API being invoked to render corresponding information. FIG. 4, with reference to FIGS. 1 through 3, depicts a flow-chart illustrating steps involved in processing the fine-tuned intent to render information, in accordance with an embodiment of the present disclosure.
[049] At step 210 of the method of the present disclosure, the one or more hardware processors 104 process the rendered information to obtain one or more candidate microservices Application Programming Interface (API) designs. The one or more candidate microservices API designs are based on at least one of one or more structured data-based files. The one or more candidate microservices Application Programming Interface (API) designs comprise at least one of a re-use microservice API design, an enhanced microservice API design, and a new microservices API design. The rendered information serves as the final metadata repository data based on which one or more candidate microservices API designs along with structured data-based files are provided. The one or more structured data-based files comprise but are not limited to swagger files, JavaScript Object Notation (json) files, and so on. While obtaining the one or more candidate microservices Application Programming Interface (API) designs, based on the fine-tuned intent the system 100 checks the one or more business requirements associated with the user to determine whether there is (i) is an existing microservice API design which can be served as a re-use microservice API design, (ii) a need for creating an altogether new microservices API design, (iii) or (iii) provide an enhanced microservice API design by making modifications to existing microservice API design. Providing enhanced microservice API design may involve modifying the current attribute list of the existing microservice API design. For example, either new attributes may be added to, or some attributes may be deleted/removed from the existing attribute list of the existing microservice API design to generate the enhanced microservice API design, thus meeting the one or more business requirements associated with the user. FIG. 5, with reference to FIGS. 1 through 4, depicts a flow-chart illustrating steps involved in processing the rendered information to obtain one or more candidate microservices Application Programming Interface (API) designs, in accordance with an embodiment of the present disclosure.
[050] At step 212 of the method of the present disclosure, the one or more hardware processors 104 register at least one microservices API design amongst the one or more candidate microservices API designs with an API platform. The at least one microservices API design is registered with the API platform for provisioning of an integration interface for integration with one or more environments (e.g., a development environment, a quality assurance environment, a user acceptance test (UAT) environment, a production environment, and so on). Depending upon the at least one microservices API design being selected or reviewed by the user, the at least one microservices API design is registered with the API platform. The registration of the at least one microservices API design involves determining an addition of a new customer, updating of enhancement associated with the existing API design, building of new API design, and so on. In an embodiment of the present disclosure, the expression ‘user’, may also referred to as ‘consumer’, or ‘customer’ and may be interchangeably used herein. However, it is to be understood by a person having ordinary skill in the art or person skilled in the art that the user may or may not consume the API design that is provided by the system 100. In other words, the API design may be consumed or utilized by another user/non-user (e.g., organization/entity/application), and so on. FIG. 6, with reference to FIGS. 1 through 5, depicts a flow-chart illustrating steps involved in registering at least one microservices API design amongst the one or more candidate microservices API designs with an API platform, in accordance with an embodiment of the present disclosure.
[051] Below illustrates various use case scenarios as implemented by the method of the present disclosure.
Scenario: API Design Discovery:
Scenario details
Given:
• The consumer is trying to determine if there is any existing API design that can address their expectation, so that the API design can be re-used as-is.
• The consumer is aware of the data required for their functionality and one or more API design journey touchpoints, such as system of record that sources the required data, entity associated with the required data, and so on.
When:
• The consumer has accessed the system 100 through either the AI Chat Application 430 or the Web Application 440 system interface touchpoint after successful Authentication and Authorization 410.
• The system 100 has navigated consumer to their Landing Page 400 and displayed the functional ‘Predefined Touchpoints’ 714 to select an existing feature on API design self-servicing experience or a ‘Prompt’ 710 to specify their intent either through text or media such as audio, image, etc.
• The consumer has provided an intent by either selecting it from the ‘Predefined Touchpoints’ 714, for example selecting the ‘API design discovery’ function touchpoint or by entering it at the ‘Prompt’ 710, for example something like ‘Search for the existing API designs’ or ‘API design discovery’, etc.
Then:
The system 100 has iteratively performed below steps until the API designs addressing the consumer’s intent are produced to consumer for review, followed by the registration.
• Step 1: Understands the consumer’s intent and expectation using ‘Identify Intent’ 710 module/component, wherein
o it captures the consumer’s intent either through the ‘Prompts’ 712 that the consumer has entered in chat interface or through selection of a ‘Predefined Touchpoint’ 714 presented to consumer based on the metadata repositories data.
o Then it transforms or maps the intent to identified metadata repository/repositories (MdR) and corresponding MdR Application Programming Interface (API) by using ‘Configuration & Standards’ 3000 and/or GPT – Custom Model’ 2000 module/component, that is trained on or refers the data from the Metadata Repositories 900.
o Finally, it passes this intent to ‘Process Intent’ 720 module/component for further processing.
• Step 2: Processes the consumer’s identified and transformed intent using the ‘Process Intent’ 720 module/component, wherein,
o It triggers the ‘Process Metadata Repository Data’ 722 function that retrieves the data from identified MdR in Metadata Repositories 900, using relevant MdR API (1100) or ‘Org API’ 1200 especially on occasions when data is required from ‘Organization Applications’ 5000.
o The retrieved data is then processed in ‘Qualify MdR Data for Display’ 728 function to transform for display to consumer.
• Step 3: Displays the data to consumer using ‘Display Processed MdR/Intent Data’ 730 module/component.
o This data may be an ‘Intermittent Intent Data’ 732 to help consumer in further narrowing down the intent or final ‘API Design and Sample JSON Data’ 734 that is identified based on user’s intent.
o If it is intermittent intent data, then consumer proceeds to further narrowing down intent by specifying fine-tuned intent and cycle continues till final API designs are identified.
o If it is the API design with sample JSON data of identified APIs, then ‘Download and Review’ 736A is provisioned to review API design to determine ‘Register API Design Use’ 736D or ‘Enhance API Design’ 736B or ‘Create New API Design’ 736C.
The Consumer reviews the API design, finds suitable API design for re-use, and proceeds on ‘Register API Design Use’ 736D function.
• Step 4: The system 100 triggers the ‘API Design Registration’ 800 module/component’s ‘Re-use API Design’ 810 function to initiate a request to API Platform team to enable the API relevant to the API design for this consumer and deploy it on the environments for integration by consumer’s application.
• Step 5: The system 100,
o Invokes the ‘Update MdR’ 840 function that updates the consumer’s use of the selected API in the ‘Subscription Metadata Repository’ 920.
o Finally calls the ‘Notification’ 850 function that communicates or notifies the acknowledgement of the API design enhancement operation to consumer.
Note:
• The consumer may have to perform certain steps to access the APIs based on organization’s API strategy. For example, register to plan in API gateway, generate token to access the API, and so on.
• The steps above may be combined or further split based on implementation strategy.
• The steps flow and/or order and/or use may vary based on the consumer’s interaction approach to system.
• In the chat API application interface, the consumer may switch from predefined touchpoint-based interaction to prompt at any time.

Example flow using predefined touchpoints for API discovery:
1. The consumer has accessed system 100 by completing the Authentication and Authorization 410 by selecting either the AI Chat Application 430 or Web Application 440 system interface touchpoint.
2. The system 100 has identified user role as ‘Consumer’ and rendered the ‘Landing Page’ 400 wherein functional touchpoints, such as ‘API design discovery’, ‘API design enhancement’, ‘API design generation’ are retrieved from Touchpoints Metadata Repository 910 using GET Touchpoints MdR API 100. Below Table 8 illustrates functional touchpoint intent, by way of examples.
Table 8

Functional Touchpoint intent: ?API design discovery ?API design enhancement ?API design generation ?Manage subscription More>>
Done Reset

3. The consumer selects the ‘API design discovery’ touchpoint.
4. The system 100 passes this intent to ‘Identify Intent’ 710 module/component where it is mapped to functional touchpoint selection category and Get Touchpoints API with request criteria containing the API design discovery touchpoint identifier and indication to retrieve the API design journey specific touchpoint categories from Touchpoints MdR 910.
5. The system 100 passes this transformed intent for processing to ‘Process Intent’ 720 module/component, that using ‘Processed MdR Data’ 722 function invokes the GET Touchpoints MdR API 1100 passing the API design discovery identifier along with other indicators and retrieves the API design journey touchpoint categories and other data under API design discovery. The ‘Qualify MdR Data for Display’ 728 function extracts the categories data such as ‘System of Record’, ‘Entity’, ‘API’, ‘Subscription’, etc. and their MdR file references. So that the consumer is displayed with these touchpoints to select a touchpoint to use in their self-servicing API design discovery experience.
6. The system 100 passes this processed intent data to ‘Display Processed MdR/Intent Data’ 730 module/component for processing the data display. After determination that the data does not include API design and sample Json, it is passed to ‘Intermittent Intent Data’ 732 function that displays the API design journey touchpoints, ‘System of Record’, ‘Entity’, ‘API’, ‘Subscription’, etc. Below Table 9 illustrates intermittent intent data, by way of examples.
Table 9
Identify API design to enhance based on: ?SoR
?Entity
?API
?Subscription
More>>
Done Reset

7. The system 100 then waits for the consumer to provide their next intent.
8. The consumer selects the ‘SoR’ that is ‘System of Record’ touchpoint as an intent indicating that they want to look for the APIs from certain or all System of Records.
9. The system 100 passes this captured intent information to the ‘Identify Intent’ 710 module/component along with the System of Record MdR file reference(s) those were retrieved in prior step. The intent information is then transformed to map to ‘SoR Master MdR’ 930 and Get SystemOfRecords MdR API 1100.
10. The system passes this transformed intent for processing to ‘Process Intent’ 720 where ‘Process MdR Data’ 722 function retrieves the list of SoRs from SoR MdR 930 using Get SystemOfRecords MdR API 1100 and pass to ‘Qualify Data for Display’ 728 function, where list of SoRs with their identifier are processed to pass for display.
11. The system 100 passes the processed intent data to ‘Display Processed MdR/Intent Data’ 730 module/component for processing the data display. After determination that the data does not include API design and sample Json, it is passed to ‘Intermittent Intent Data’ 732 function that displays the system of records touchpoints, such as ‘SoR1’, ‘SoR2’, ‘SoR3’, and so on. It also provisions to select ‘All SoRs’. Below Table 10 illustrates SoR touchpoints, by way of examples.
Table 10

SoRs ?SoR1
?SoR2
?SoR3
?SoR4
More>>
Entities ?ENT1
?ENT2
?ENT3
?ENT4
More>>
Products ?PRD1
?PRD2
?PRD3
?PRD4
More>>
All SoRs Done Reset

12. The system 100 then waits for the consumer to provide their next intent.
13. The consumer selects the ‘SoR3’ touchpoint as intent indicating that they want to look for the APIs exposing the data from SoR3.
14. The system 100 passes this captured intent information to the ‘Identify Intent’ 710 module/component. The information may contain details such as touchpoint selected is ‘SoR’, its identifier. The intent information is then transformed to map to ‘API Master MdR’ 950 and Get APIs MdR API 1100.
15. The system passes this transformed intent for processing to ‘Process Intent’ 720 where ‘Process MdR Data’ 722 function retrieves the list of APIs from API MdR 950 using Get APIs MdR API 1100 where systemOfRecord for the data exposed by API includes ‘SoR3’ and pass this API response to ‘Qualify Data for Display’ 728 function, where hyperlinks are created for the qualified APIs and their sample Json files and provided it for display.
16. The system 100 passes the processed intent data to ‘Display Processed MdR/Intent Data’ 730 module/component for processing the data display. After determination that the data includes the reference to API design and sample Json files, it is passed to ‘API Design and Sample Json’ 734 function for display with provision to download for review (736). Below Table 11 illustrates API designs and sample JSONs, by way of examples.
Table 11

SoR3 API Designs GET ?/v1/claims/search
API design Sample Json More>>
GET ?/v1/claims/{id}
API design Sample Json More>>
POST ?/v1/claims/{id}
API design Sample Json More>>
GET ?/v1/claims/{id}/payments
API design Sample Json More>>
More>>
Done Reset

17. The system 100 then waits for the consumer to provide their next intent. The consumer reviews the file online or downloads it for offline review.
18. After review, the consumer selects an API, from list of APIs sourcing data from SoR3, to proceed with ‘Register API Design Use’ 736D action.
19. The system 100 passes the consumer’s API design registration intent to ‘API Design Registration’ 800 module/component. From the data passed to this module/component it determines that the request is for re-use and hence maps it to ‘Re-use API Design’ 810 function. This function initiates the workflow request to API Platform team passing the API design and consumer details to enable this API for consumption to the consumer and deploy it on environments.
20. The system 100 sends/displays the acknowledgement notification to consumer.
21. The consumer may take the API design file and sample Json to proceed on the design and development. The consumer can integrate the actual API once it is published on environment by API platform team.
Note:
• The above flow of events may vary based on consumer’s interaction with the system 100.
• The number of touchpoints that the consumer must touch to interact varies based on the consumer’s interaction with the system 100.
o For example, if consumer chose to use prompt-based interaction approach and specify the complete intent that helped system 100 to narrow down to the suitable API(s), then the system 100 must present the list of API designs satisfying the consumer’s intent.
Scenario: API Design Enhancement.
Scenario details
Given:
• The consumer is enhancing existing functionality to add more data elements thereby needing to enhance an existing API design that services the data to fulfil that business use case.
• The Consumer is aware of the API design, business use case, as well as the system of record from where additional fields need to be returned in the API.
When:
• The consumer has accessed the system 100 through either the AI Chat Application 430 or the Web Application 440 system interface touchpoint after successful Authentication and Authorization 410.
• The system 100 has navigated consumer to their Landing Page 400 and displayed the functional ‘Predefined Touchpoints’ 714 to select an existing feature on API design self-servicing experience or a ‘Prompt’ 710 to specify their intent either through text or media such as audio, image, etc.
• The consumer has provided an intent by either selecting it from the ‘Predefined Touchpoints’ 714, for example selecting the ‘API design enhancement’ function touchpoint or by entering it at the ‘Prompt’ 710, for example something like ‘Enhance the existing API design’ or ‘Modify the existing API design’, etc.
Then:
The system 100 has iteratively performed below steps until the API design addressing the consumer’s intent is produced to consumer for review, followed by the registration.
• Step 1: Understands the consumer’s intent and expectation using ‘Identify Intent’ 710 module/component, wherein
o it captures the consumer’s intent either through the ‘Prompts’ 712 that the consumer has entered in chat interface or through selection of a ‘Predefined Touchpoint’ 714 presented to consumer based on the metadata repositories data.
o Then it transforms or maps the intent to identified metadata repository/repositories (MdR) and corresponding MdR Application Programming Interface (API) by using ‘Configuration & Standards’ 3000 and/or GPT – Custom Model‘ 2000 module/component, that is trained on or refers the data from the Metadata Repositories 900.
o Finally, it passes this intent to ‘Process Intent’ 720 module/component for further processing.
• Step 2: Processes the consumer’s identified and transformed intent using the ‘Process Intent’ 720 module/component, wherein,
o It triggers,
? the ‘Enhance API Design’ 724 function that refers the industry and organization level API design standards in ‘Configuration and Standards’ 3000 along with the ‘Attributes MdR’ 970 to define the attribute definition for the newly added attributes in API design.
? the ‘Process Metadata Repository Data’ 722 function that retrieves the data from identified MdR in Metadata Repositories 900, using relevant MdR API (1100) or ‘Org API’ 1200, especially on occasions when data is required from ‘Organization Applications’ 5000.
o The retrieved data or attribute definitions added to enhanced API design is then processed in ‘Qualify MdR Data for Display’ 728 function to transform for display to consumer.
• Step 3: Displays the data to consumer using ‘Display Processed MdR/Intent Data’ 730 module/component.
o This data may be an ‘Intermittent Intent Data’ 732 to help consumer in further narrowing down the intent or final ‘API Design and Sample JSON Data’ 734 that is identified based on user’s intent.
o If it is intermittent intent data, then consumer proceeds to further narrowing down intent by specifying fine-tuned intent and cycle continues till final API designs are identified.
o If it is the API design with sample JSON data of identified APIs, then ‘Download and Review’ 736A is provisioned to review API design to determine ‘Register API Design Use’ 736D or ‘Enhance API Design’ 736B or ‘Create New API Design’ 736C.
The Consumer selects the API design that is used in the current functionality that needs to be enhanced to add more attributes to it and proceeds to ‘Enhance API Design’ 736B.
The system 100 iteratively performs the Step 1 to Step 3 to,
• identify and process the consumer’s intent of adding the attributes based on the API design journey touchpoints such as System of Record or Entity or other API.
• displaying the list of attributes to add to request and/or response of the existing API design based on consumer’s selection of attributes through touchpoint or specification at prompt.
• creating the attribute definitions for newly added attributes in API design to generate an enhanced API design with sample Json for consumer’s review.
• passing indication of enhanced API design use to ‘Register Design Use’ 736D function to proceed on registration.
• Step 4: The system 100 triggers the ‘API Design Registration’ 800 module/component’s ‘Enhance API Design’ 820 function to initiate a request to API Platform team to develop an enhancement to the API design for this consumer and deploy it on the environments for integration by consumer’s application.
• Step 5: The system 100,
o Invokes the ‘Update MdR’ 840 function that updates the ‘API Metadata Repository’ 950 to refer the update schema and example file references having the new attribute definitions.
o Finally calls the ‘Notification’ 850 function that communicates or notifies the acknowledgement of the API design enhancement operation to consumer.
Note:
• The consumer may have to perform certain steps to access the APIs based on organization’s API strategy. For example, register to plan in API gateway, generate token to access the API, and so on.
• The steps above may be combined or further split based on implementation strategy.
• The steps flow and/or order and/or use may vary based on the consumer’s interaction approach to system.
• In the chat API application interface, the consumer may switch from predefined touchpoint-based interaction to prompt at any time.
Example flow using predefined touchpoints for API enhancement:
1. Consumer has accessed system 100 by completing the Authentication and Authorization 410 by selecting either the AI Chat Application 430 or Web Application 440 system interface touchpoint.
2. The system 100 has identified user role as ‘Consumer’ and rendered the ‘Landing Page’ 400 wherein functional touchpoints, such as ‘API design discovery’, ‘API design enhancement’, ‘API design generation’ are retrieved from Touchpoints Metadata Repository 910 using GET Touchpoints MdR API 100. Below Table 12 illustrates functional touchpoints, by way of examples.
Table 12
Functional Touchpoint intent: ?API design discovery ?API design enhancement ?API design generation ?Manage subscription More>>
Done Reset

3. The consumer selects the ‘API design enhancement’ touchpoint.
4. The system 100 passes this intent to ‘Identify Intent’ 710 module/component where it is mapped to a functional touchpoint selection category and Get Touchpoints API with request criteria containing the API design enhancement touchpoint identifier and indication to retrieve the API design journey specific touchpoint categories from Touchpoints MdR 910.
5. The system 100 passes this transformed intent for processing to ‘Process Intent’ 720 module/component, that using ‘Processed MdR Data’ 722 function invokes the GET Touchpoints MdR API 1100 passing the API design enhancement identifier along with other indicators and retrieves the API design journey touchpoint categories and other data under API design enhance. The ‘Qualify MdR Data for Display’ 728 function extracts the categories data such as ‘System of Record’, ‘Entity’, ‘API’, ‘Subscription’, etc. and their MdR file references. So that the consumer is displayed with these touchpoints to select a touchpoint to use in their self-servicing API design enhancement experience to retrieve the list of attributes to select for adding to the API design.
6. The system 100 passes this processed intent data to ‘Display Processed MdR/Intent Data’ 730 module/component for processing the data display. After determination that the data does not include API design and sample Json, it is passed to ‘Intermittent Intent Data’ 732 function that displays the API design journey touchpoints, ‘System of Record’, ‘Entity’, ‘API’, ‘Subscription’, etc. Below Table 13 illustrates API design journey touchpoints, by way of examples.
Table 13

Identify API design to enhance based on: ?SoR
?Entity
?API
?Subscription
More>>
Done Reset

7. The system 100 then waits for the consumer to provide their next intent.
8. The consumer selects the ‘Subscription’ touchpoint as an intent indicating that they want to retrieve list of all the APIs under their subscription so that they can select an API to enhance.
9. The system 100 passes this captured intent information to the ‘Identify Intent’ 710 module/component along with the Subscription MdR file reference(s) and consumer identifier those were retrieved in prior step. The intent information is then transformed to map to ‘Subscription Master MdR’ 920 and Get Subscriptions MdR API 1100.
10. The system passes this transformed intent for processing to ‘Process Intent’ 720 where ‘Process MdR Data’ 722 function retrieves the list of consumer’s subscriptions from Subscription MdR 920 using Get Subscriptions MdR API 1100 and pass it to ‘Qualify Data for Display’ 728 function, where list of subscriptions with their identifier are processed to pass for display.
11. The system 100 passes the processed intent data to ‘Display Processed MdR/Intent Data’ 730 module/component for processing the data display. After determination that the data does not include API design and sample Json, it is passed to ‘Intermittent Intent Data’ 732 function that displays the subscriptions touchpoints, such as ‘get-claims-subscription’, ‘register-user-subscription’, ‘party-search-subscription’, and so on. Below Table 14 illustrates subscription touchpoints, by way of examples.
Table 14

Consumer1 subscriptions ?get-claims-subscription ?register-user-subscription ?party-search-subscription More>>
Done Reset

12. The system 100 then waits for the consumer to provide their next intent.
13. The consumer selects the ‘get-claims-subscription’ touchpoint as intent indicating that they want to look for the APIs under the ‘get-claims-subscription’.
14. The system 100 passes this captured intent information to the ‘Identify Intent’ 710 module/component. The information may contain details such as touchpoint selected is ‘get-claims-subscription’, its identifier. The intent information is then transformed to map to ‘Subscription Master MdR’ 920 and Get Subscriptions MdR API 1100.
15. The system passes this transformed intent for processing to ‘Process Intent’ 720 where ‘Process MdR Data’ 722 function retrieves the list of APIs from Subscription MdR 920 using Get Subscriptions MdR API 1100 where consumer identifier is this consumer and subscription id is get-claims-subscription. The API response is then passed to ‘Qualify Data for Display’ 728 function, where hyperlinks are created for the qualified APIs and their sample Json files and provided it for display.
16. The system 100 passes the processed intent data to ‘Display Processed MdR/Intent Data’ 730 module/component for processing the data display. After determination that the data includes the reference to API design and sample Json files, it is passed to ‘API Design and Sample Json’ 734 function for display with provision to download for review (736A). Below Table 15 illustrates API design and sample JSONs, by way of examples.
Table 15

get-claims-subscription APIs GET ?/v1/claims/search
API design Sample Json More>>
GET ?/v1/claims/{id}
API design Sample Json More>>
POST ?/v1/claim/{id}
API design Sample Json More>>
Done Reset

17. The system 100 then waits for the consumer to provide their next intent.
18. The consumer selects the API design from the list of API designs, under get-claims-subscription, to enhance and proceed with ‘Enhance API Design’ 736B action.
19. The system 100 passes the consumer’s API design enhancement intent with the selected API design to ‘Identify Intent’ 710 function.
20. The steps 4, 5, and 6 are repeated to display the API journey touchpoints, ‘System of Record’, ‘Entity’, and ‘API’ to consumer to select a touchpoint based on which the list of attributes will be retrieved from MdR for selection to add to request and response of API design. Below Table 16 illustrates attributes for selection, by way of examples.
Table 16

Attributes based on: ?SoR
?Entity
?API
?Subscription
More>>
Done Reset

21. The system 100 then waits for the consumer to provide their next intent.
22. The consumer selects the ‘System of Record’ as a touchpoint to retrieve the list of attributes.
23. The consumer selects the ‘System of Record’ (SoR) touchpoint as intent indicating that they want to add attributes to the selected API design from a certain System of Record(s).
24. The system 100 passes this captured intent information to the ‘Identify Intent’ 710 module/component along with the System of Record MdR file reference(s) those were retrieved in prior step. The intent information is then transformed to map to ‘SoR Master MdR’ 930 and Get SystemOfRecords MdR API 1100.
25. The system passes this transformed intent for processing to ‘Process Intent’ 720 where ‘Process MdR Data’ 722 function retrieves the list of SoRs from SoR MdR 930 using Get SystemOfRecords MdR API 1100 and pass to ‘Qualify Data for Display’ 728 function, where list of SoRs with their identifier are processed to pass for display.
26. The system 100 passes the processed intent data to ‘Display Processed MdR/Intent Data’ 730 module/component for processing the data display. After determination that the data does not include API design and sample Json, it is passed to ‘Intermittent Intent Data’ 732 function that displays the system of records touchpoints, such as ‘SoR1’, ‘SoR2’, ‘SoR3’, and so on. It also provisions to select ‘All SoRs’. Below Table 17 illustrates SoR touchpoints, by way of examples.
Table 17

SoRs ?SoR1
?SoR2
?SoR3
?SoR4
More>>
Entities ?ENT1
?ENT2
?ENT3
?ENT4
More>>
Products ?PRD1
?PRD2
?PRD3
?PRD4
More>>
Done Reset

27. The system 100 then waits for the consumer to provide their next intent.
28. The consumer selects the ‘SoR3’ touchpoint as intent indicating that they want to add attributes to the selected API design from SoR3.
29. The system 100 passes this captured intent information to the ‘Identify Intent’ 710 module/component. The information may contain details such as touchpoint selected is ‘SoR3’, its identifier. The intent information is then transformed to map to ‘Attributes Master MdR’ 970 and Get Attributes MdR API 1100.
30. The system passes this transformed intent for processing to ‘Process Intent’ 720 where ‘Process MdR Data’ 722 function retrieves the list of Attributes from Attributes MdR 950 using Get Attributes MdR API 1100 where systemOfRecord associated with the attribute contains ‘SoR3’. It then passes this API response to ‘Qualify Data for Display’ 728 function, where searchable attributes are included in request as well as response list for display while non-searchable attributes are included in response attribute list.
31. The system 100 passes the processed intent data to ‘Display Processed MdR/Intent Data’ 730 module/component for processing the data display. After determination that the data does not include the reference to API design, it is passed to ‘Intermittent Intent Data’ 732 function that displays the request attributes list and response attributes list in tabular fashion with provision to select the attributes to include in request and response. Below Table 18 illustrates selection of attribute(s) for request and response, by way of examples.
Table 18

Request ?ATTR1
?ATTR5
?ATTR6
?ATTR12
More>>
Response ?ATTR10
?ATTR11
?ATTR12
?ATTR4
More>>
Remove Add Reset

32. The system 100 then waits for the consumer to provide their next intent.
33. The consumer selects the attributes to add in response of API design and optionally selects the attributes to include in API design request to help retrieve the additional attributes from SoR3. The consumer proceeds by selecting ‘Add’ action.
34. The system 100 passes this captured intent information to the ‘Identify Intent’ 710 module/component. The information may contain details such as API design identifier, request and response attributes list, and add/remove/modify action. The intent information is then transformed to enhance API design with completed attribute selection.
35. The system passes this transformed intent for processing to ‘Process Intent’ 720 where it invokes the ‘Enhance API Design’ 724 function that uses ‘API Design Standards’ 3000 module/component to identify the suitable definitions for the new attributes and generate the modified API design with these attributes. It also generates the API design sample Json with new attributes and passes this enhanced API design to ‘Qualify Data for Display’ 728 function, where it creates the hyperlinks for the API design and sample Json files.
36. The system 100 passes the processed intent data to ‘Display Processed MdR/Intent Data’ 730 module/component for processing the data display. After determination that the data includes the reference to API design and sample Json files, it is passed to ‘API Design and Sample Json’ 734 function for display with provision to download for review (736). Below Table 19 illustrates API designs and sample JSONs, by way of examples.
Table 19

get-claims-subscription APIs GET ?/v1/claims/search
API design Sample Json More>>
Create API Design Enhance API Design Register Use Cancel

37. The system 100 then waits for the consumer to provide their next intent. The consumer reviews the file online or downloads it for offline review.
38. After review, consumer confirms update by selecting the enhanced API design and proceeding with ‘Register API Design Use’ 736D action.
39. The system 100 passes the consumer’s API design registration intent to ‘API Design Registration’ 800 module/component. From the data passed to this module/component it determines that the request is for (1) enhancing the API design and (2) update the consumer’s use of this enhanced API design. Hence the module/component maps it to ‘Enhance API Design’ 820 function and ‘Update MdR’ 840 function.
a. The ‘Enhance API Design’ 820 function initiates the workflow request to API Platform team passing the API design and consumer details to enhance this API design with newly added attributes and deploy it on environments.
b. The ‘Update MdR’ 840 function updates the API Metadata Repository 950 with additional attributes for this consumer’s use of the API design.
40. The system 100 sends/displays the acknowledgement notification to consumer.
41. The consumer may take the API design file and sample Json to proceed on the design and development. The consumer can integrate the actual API once it is published on environment by API platform team.
Note:
• The above flow of events may vary based on consumer’s interaction with the system 100.
• The number of touchpoints that the consumer must touch to interact varies based on the consumer’s interaction with the system 100.
o For example, if consumer chose to use prompt-based interaction approach and specify the complete intent that helped system 100 to narrow down to the suitable API(s), then the system 100 must present the list of API designs satisfying the consumer’s intent.
Scenario: API Design Generation.
Scenario details
Given:
• The consumer is trying to generate a new API design to address their expectation,
• The consumer is aware of the source system and/or entity of their business function’s data expectation.
• The consumer is aware of the data attributes available in their functionality to retrieve the data attributes related to the entity from system of record(s).
When:
• The consumer has accessed the system 100 through either the AI Chat Application 430 or the Web Application 440 system interface touchpoint after successful Authentication and Authorization 410.
• The system 100 has navigated consumer to their Landing Page 400 and displayed the functional ‘Predefined Touchpoints’ 714 to select an existing feature on API design self-servicing experience or a ‘Prompt’ 710 to specify their intent either through text or media such as audio, image, etc.
• The consumer has provided an intent by either selecting it from the ‘Predefined Touchpoints’ 714, for example selecting the ‘API design generation’ function touchpoint or by entering it at the ‘Prompt’ 710, for example something like ‘Create a new API design’ or ‘Generate an API design’, etc.
Then:
The system 100 has iteratively performed below steps until the API design addressing the consumer’s intent is produced to consumer for review, followed by the registration.
• Step 1: Understands the consumer’s intent and expectation using ‘Identify Intent’ 710 module/component, wherein
o it captures the consumer’s intent either through the ‘Prompts’ 712 that the consumer has entered in chat interface or through selection of a ‘Predefined Touchpoint’ 714 presented to consumer based on the metadata repositories data.
o Then it transforms or maps the intent to identified metadata repository/repositories (MdR) and corresponding MdR Application Programming Interface (API) by using ‘Configuration & Standards’ 3000 and/or GPT – Custom Model‘ 2000 module/component, that is trained on or refers the data from the Metadata Repositories 900.
o Finally, it passes this intent to ‘Process Intent’ 720 module/component for further processing.
• Step 2: Processes the consumer’s identified and transformed intent using the ‘Process Intent’ 720 module/component, wherein,
o It triggers,
? the ‘Create API Design’ 726 function that after capturing the consumer’s expectation such as data retrieval vs data update to determine the HTTP method for the API design and iteratively collecting the request and response attributes using ‘Attributes MdR’ 970, refers the industry and organization level API design standards in ‘Configuration and Standards’ 3000 module/component to define the attribute definitions and rest of the API design such as structure.
? the ‘Process Metadata Repository Data’ 722 function that retrieves the data from identified MdR in Metadata Repositories 900, using relevant MdR API (1100) or ‘Org API’ 1200, especially on occasions when data is required from ‘Organization Applications’ 5000.
o The retrieved data or attribute definitions added to new API design is then processed in ‘Qualify MdR Data for Display’ 728 function to transform for display to consumer.
• Step 3: Displays the data to consumer using ‘Display Processed MdR/Intent Data’ 730 module/component.
o This data may be an ‘Intermittent Intent Data’ 732 to help consumer in further narrowing down the intent or final ‘API Design and Sample JSON Data’ 734 that is identified based on user’s intent.
o If it is intermittent intent data, then consumer proceeds to further narrowing down intent by specifying fine-tuned intent and cycle continues till final API design is generated.
o If it is the API design with sample JSON data, then ‘Download and Review’ 736A is provisioned to review API design to determine ‘Register API Design Use’ 736D or ‘Enhance API Design’ 736B or ‘Create New API Design’ 736C.
The consumer selects the newly generated API design, reviews the attributes to ensure it fulfils consumer’s functional requirement expectation, and proceeds to ‘Register API Design Use’ 736D of the newly created API design.
• Step 4: The system 100 triggers the ‘API Design Registration’ 800 module/component’s ‘Create API Design’ 820 function to initiate a request to API Platform team to develop a new API design for this consumer and deploy it on the environments for integration by consumer’s application.
• Step 5: The system 100,
o Invokes the ‘Update MdR’ 840 function that updates all the relevant metadata repositories for the newly created API design, such as ‘APIs Metadata Repository’ 950, ‘Use Cases Metadata Repository’ 960, ‘Subscriptions Metadata Repository’ 920, and so on, to add entry for the new API design and/or its attributes or reference.
o Finally calls the ‘Notification’ 850 function that communicates or notifies the acknowledgement of the API design generation operation to consumer.
Note:
• The consumer may have to perform certain steps to access the APIs based on the organization’s API strategy. For example, register to plan in API gateway, generate token to access the API, and so on.
• The steps above may be combined or further split based on implementation strategy.
• The steps flow and/or order and/or use may vary based on the consumer’s interaction approach to system.
• In the chat API application interface, the consumer may switch from predefined touchpoint-based interaction to prompt at any time.
Example flow using predefined touchpoints for API generation:
1. The consumer has accessed system 100 by completing the Authentication and Authorization 410 by selecting either the AI Chat Application 430 or Web Application 440 system interface touchpoint.
2. The system 100 has identified user role as ‘Consumer’ and rendered the ‘Landing Page’ 400 wherein functional touchpoints, such as ‘API design discovery’, ‘API design enhancement’, ‘API design generation’ are retrieved from Touchpoints Metadata Repository 910 using GET Touchpoints MdR API 100. Below Table 20 illustrates functional touchpoint, by way of examples.
Table 20

Functional Touchpoint intent: ?API design discovery ?API design enhancement ?API design generation ?Manage subscription More>>
Done Reset

3. The consumer selects the ‘API design generation’ touchpoint.
a. The consumer may have completed the ‘API design discovery’ and found no suitable API design to use for their functionality. For example, the consumer is trying to onboard a completely new functionality like registration that wasn’t provisioned in consumer organization before.
b. The consumer may not have already completed ‘API design discovery’ because the consumer is aware that there is no API design in API platform that fulfils their expectation, or they simply avoided ‘API design discovery’.
i. Note: Except the consumer has already completed ‘API design discovery’ in same session, the system 100 after capturing the consumer’s intent, such as retrieving the data vs updating the data in system and attributes to include in request and response of the API design, always perform API design discovery in background to find if any API design exist that either completely or partially addresses the consumer’s intent. It then presents such API designs to consumer and confirms if any of the identified APIs can be re-used or enhanced to meet the expectation before creating the new API design.
ii. Also, the API platform team, as part of their API design implementation performs validation of existing API designs and encourages the consumer to re-use as-is or with enhancement the existing API design than creating new.
4. The system 100 passes this intent to ‘Identify Intent’ 710 module/component where it is mapped to a functional touchpoint selection category and Get Touchpoints API with request criteria containing the API design generation touchpoint identifier and indication to retrieve the API design journey specific touchpoint categories from Touchpoints MdR 910.
5. The system 100 passes this transformed intent for processing to ‘Process Intent’ 720 module/component, that using ‘Processed MdR Data’ 722 function invokes the GET Touchpoints MdR API 1100 passing the API design generation identifier along with other indicators and retrieves the API design journey touchpoint categories and other data under API design generation. The ‘Qualify MdR Data for Display’ 728 function extracts the categories data such as ‘System of Record’, ‘Entity’, ‘API’, ‘Subscription’, etc. and their MdR file references. So that the consumer is displayed with these touchpoints to select a touchpoint to use for starting the self-servicing experience of creating the new API design.
6. The system 100 passes this processed intent data to ‘Display Processed MdR/Intent Data’ 730 module/component for processing the data display. After determination that the data does not include API design and sample Json, it is passed to ‘Intermittent Intent Data’ 732 function that displays the API design journey touchpoints, ‘System of Record’, ‘Entity’, ‘API’, ‘Use Case’, ‘Subscription’, etc. Below Table 21 illustrates API design journey touchpoints, by way of examples.
Table 21

Create API design starting with: ?SoR
?Entity
?API
?Use Case More>>
Done Reset

7. The system 100 then waits for the consumer to provide their next intent.
8. The consumer selects the ‘SoR’, that is System of Record’ touchpoint as an intent indicating that they want to start new API design by selecting the system of record and then the attributes from the selected system of record.
9. The system 100 passes this captured intent information to the ‘Identify Intent’ 710 module/component along with the System of Record MdR file reference(s). The intent information is then transformed to map to ‘SoR Master MdR’ 920 and Get SystemOfRecords MdR API 1100.
10. The system passes this transformed intent for processing to ‘Process Intent’ 720 where ‘Process MdR Data’ 722 function retrieves the list of SoRs from SoR MdR 930 using Get SystemOfRecords MdR API 1100 and pass to ‘Qualify Data for Display’ 728 function, where list of SoRs with their identifier are processed to pass for display.
11. The system 100 passes the processed intent data to ‘Display Processed MdR/Intent Data’ 730 module/component for processing the data display. After determination that the data does not include API design and sample Json, it is passed to ‘Intermittent Intent Data’ 732 function that displays the system of records touchpoints, such as ‘SoR1’, ‘SoR2’, ‘SoR3’, and so on. It also provisions to select ‘All SoRs’. Below Table 22 illustrates SoR touchpoints, by way of examples.
Table 22

SoRs ?SoR1
?SoR2
?SoR3
?SoR4
More>>
Entities ?ENT1
?ENT2
?ENT3
?ENT4
More>>
Products ?PRD1
?PRD2
?PRD3
?PRD4
More>>
All SoRs Done Reset

12. The system 100 then waits for the consumer to provide their next intent.
13. The consumer selects the ‘SoR3’, ‘ENT1’, and ‘ENT2’ touchpoints as intent indicating that they want to create and API design using the system of record as SoR3, and the data attributes related to entities ENT1 and ENT2 from SoR3.
14. The system 100 passes this captured intent information to the ‘Identify Intent’ 710 module/component. The information may contain details such as touchpoints selected is ‘SoR3’, ‘ENT1’, and ‘ENT2’, their identifiers, and so on. The intent information is then transformed to map to ‘Attributes Master MdR’ 970 and Get Attributes MdR API 1100.
15. The system passes this transformed intent for processing to ‘Process Intent’ 720 where ‘Process MdR Data’ 722 function retrieves the list of Attributes from Attributes MdR 950 using Get Attributes MdR API 1100 where systemOfRecord associated with the attribute contains ‘SoR3’ and entities associated with the attribute contains ‘ENT1’ or ‘ENT2’. It then passes this API response to ‘Qualify Data for Display’ 728 function, where searchable attributes are included in request as well as response list for display while non-searchable attributes are included in response attribute list.
16. The system 100 passes the processed intent data to ‘Display Processed MdR/Intent Data’ 730 module/component for processing the data display. After determination that the data does not include the reference to API design, it is passed to ‘Intermittent Intent Data’ 732 function that displays the request attributes list and response attributes list in tabular fashion with provision to select the attributes to include in request and response. Below Table 23 illustrates attribute(s) selection for request and response, by way of examples.
Table 23

Request ?ATTR1
?ATTR5
?ATTR6
?ATTR12
More>>
Response ?ATTR10
?ATTR11
?ATTR12
?ATTR4
More>>
Remove Add Reset

17. The system 100 then waits for the consumer to provide their next intent.
18. The consumer selects the attributes to add in the request and response of the API design. The consumer proceeds by selecting ‘Add’ action.
19. The system 100 passes this captured intent information to the ‘Identify Intent’ 710 module/component. The information may contain details such as API design identifier, method identified based on the consumer’s use of data, the request and the response attributes list, and add/remove/modify action that the consumer has selected. The intent information is then transformed to create API design with completed attribute selection.
20. The system passes this transformed intent for processing to ‘Process Intent’ 720 where it invokes the ‘Create API Design’ 724 function that,
a. First performs search in the existing API design to determine if there is any existing API design that includes the attributes that the consumer has selected.
b. If found, then it presents the same to consumer for confirmation to use any of those API designs as-is or with enhancements or with different version of the endpoint.
i. If the consumer confirms to re-use with enhancements, then proceeds on the ‘Enhance API design’ processing.
ii. If the consumer confirms to not use any of the existing API designs and decides to create new, then the system 100 proceeds to generate new API design.
c. If not found, then the system 100 proceeds to generate new API design, wherein it uses the ‘API Design Standards’ 3000 module/component to identify the suitable definitions for the API endpoint, its attributes, structure, etc. and creates the new API design with selected request and response attributes. It also creates the API design sample Json and passes the API design and sample Json to ‘Qualify Data for Display’ 728 function, where it creates the hyperlinks for the API design and sample Json files.
21. The system 100 passes the processed intent data to ‘Display Processed MdR/Intent Data’ 730 module/component for processing the data display. After determination that the data includes the reference to API design and sample Json files, it is passed to ‘API Design and Sample Json’ 734 function for display with provision to download for review (736). Below Table 24 illustrates API design and sample JSONs, by way of examples.
Table 24

New API Design POST ?/v1/claims/{id}/paymentAccount API design Sample Json More>>
Create API Design Enhance API Design Register Use Cancel

22. The system 100 then waits for the consumer to provide their next intent. The consumer reviews the file online or downloads it for offline review.
23. After review, the consumer confirms the new API design and proceeds with ‘Register API Design Use’ 736D action.
24. The system 100 passes the consumer’s API design registration intent to ‘API Design Registration’ 800 module/component. From the data passed to this module/component it determines that the request is for (1) generating new API design and (2) update the consumer’s use of this new API design. Hence the module/component maps it to ‘Create API Design’ 830 function and ‘Update MdR’ 840 function.
a. The ‘Create API Design’ 830 function initiates the workflow request to API Platform team passing the API design and consumer details to implement this new API design and deploy it on environments.
b. The ‘Update MdR’ 840 function updates all the relevant metadata repositories for the newly created API design, such as ‘APIs Metadata Repository’ 950, ‘Use Cases Metadata Repository’ 960, ‘Subscriptions Metadata Repository’ 920, and so on, to add entry for the new API design and/or its attributes or reference.
25. The system 100 sends/displays the acknowledgement notification to consumer.
26. The consumer may take the API design file and sample Json to proceed on the design and development. The consumer can integrate the actual API once it is published on environment by API platform team.
Note:
• The above flow of events may vary based on consumer’s interaction with the system 100.
• The number of touchpoints that the consumer must touch to interact varies based on the consumer’s interaction with the system 100.
o For example, if consumer chose to use prompt-based interaction approach and specify the complete intent that helped system 100 to narrow down to the suitable API(s), then the system 100 must present the list of API designs satisfying the consumer’s intent.
[052] The written description describes the subject matter herein to enable any person skilled in the art to make and use the embodiments. The scope of the subject matter embodiments is defined by the claims and may include other modifications that occur to those skilled in the art. Such other modifications are intended to be within the scope of the claims if they have similar elements that do not differ from the literal language of the claims or if they include equivalent elements with insubstantial differences from the literal language of the claims.
[053] It is to be understood that the scope of the protection is extended to such a program and in addition to a computer-readable means having a message therein; such computer-readable storage means contain program-code means for implementation of one or more steps of the method, when the program runs on a server or mobile device or any suitable programmable device. The hardware device can be any kind of device which can be programmed including e.g., any kind of computer like a server or a personal computer, or the like, or any combination thereof. The device may also include means which could be e.g., hardware means like e.g., an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or a combination of hardware and software means, e.g., an ASIC and an FPGA, or at least one microprocessor and at least one memory with software processing components located therein. Thus, the means can include both hardware means and software means. The method embodiments described herein could be implemented in hardware and software. The device may also include software means. Alternatively, the embodiments may be implemented on different hardware devices, e.g., using a plurality of CPUs.
[054] The embodiments herein can comprise hardware and software elements. The embodiments that are implemented in software include but are not limited to, firmware, resident software, microcode, etc. The functions performed by various components described herein may be implemented in other components or combinations of other components. For the purposes of this description, a computer-usable or computer readable medium can be any apparatus that can comprise, store, communicate, propagate, or transport the program for use by or in connection with the instruction execution system, apparatus, or device.
[055] 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 of the disclosed embodiments. Also, the words “comprising,” “having,” “containing,” and “including,” and other similar forms are intended to be equivalent in meaning and be open ended in that an item or items following any one of these words is not meant to be an exhaustive listing of such item or items, or meant to be limited to only the listed item or items. 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.
[056] Furthermore, one or more computer-readable storage media may be utilized in implementing embodiments consistent with the present disclosure. A computer-readable storage medium refers to any type of physical memory on which information or data readable by a processor may be stored. Thus, a computer-readable storage medium may store instructions for execution by one or more processors, including instructions for causing the processor(s) to perform steps or stages consistent with the embodiments described herein. The term “computer-readable medium” should be understood to include tangible items and exclude carrier waves and transient signals, i.e., be non-transitory. Examples include random access memory (RAM), read-only memory (ROM), volatile memory, nonvolatile memory, hard drives, CD ROMs, DVDs, flash drives, disks, and any other known physical storage media.
[057] It is intended that the disclosure and examples be considered as exemplary only, with a true scope of disclosed embodiments being indicated by the following claims.
, Claims:

1. A processor implemented method, comprising:
identifying, via one or more hardware processors, one or more touchpoints from a plurality of categories (202), wherein the one or more touchpoints is based on a selection by a user and are specific to one or more business requirements associated with the user;
capturing and identifying, via the one or more hardware processors, an intent of the user from the selected one or more touchpoints (204);
iteratively processing, by using a machine learning model via the one or more hardware processors, the intent of the user based on a selection of one or more associated keywords and attributes that are queried in one or more metadata repositories and one or more configuration files to obtain a fine-tuned intent pertaining to the user (206);
processing, via the one or more hardware processors, the fine-tuned intent to render information from the one or more metadata repositories pertaining to the selected one or more touchpoints, wherein the rendered information maps to the fine-tuned intent of the user (208);
processing, via the one or more hardware processors, the rendered information to obtain one or more candidate microservices Application Programming Interface (API) designs, wherein the one or more candidate microservices API designs are based on at least one of one or more structured data-based files; and
registering, via the one or more hardware processors, at least one microservices API design amongst one or more candidate microservices API designs with an API platform (212), wherein the at least one microservices API design is registered with the API platform for provisioning of an integration interface for integration with one or more environments.

2. The processor implemented method as claimed in claim 1, wherein the registered microservices API design is specific to the one or more business requirements associated with the user.

3. The processor implemented method as claimed in claim 1, wherein the one or more candidate microservices API designs comprise at least one of a re-use microservice API design, an enhanced microservice API design, and a new microservices API design.

4. The processor implemented method as claimed in claim 1, wherein the one or more metadata repositories are queried to render the information based on an associated property file.

5. The processor implemented method as claimed in claim 1, wherein the one or more touchpoints comprise at least one of one or more system interface touchpoints, one or more API design functional touchpoints, and one or more API design journey touchpoints.

6. A system (100), comprising:
a memory (102) storing instructions;
one or more communication interfaces (106); and
one or more hardware processors (104) coupled to the memory (102) via the one or more communication interfaces (106), wherein the one or more hardware processors (104) are configured by the instructions to:
identify one or more touchpoints from a plurality of categories, wherein the one or more touchpoints is based on a selection by a user and are specific to one or more business requirements associated with the user;
capture and identify an intent of the user from the selected one or more touchpoints;
iteratively process, by using a machine learning model, the intent of the user based on a selection of one or more associated keywords and attributes that are queried in one or more metadata repositories, and one or more configuration files to obtain a fine-tuned intent pertaining to the user;
process the fine-tuned intent to render information from the one or more metadata repositories pertaining to the selected one or more touchpoints, wherein the rendered information maps to the fine-tuned intent of the user;
process the rendered information to obtain one or more candidate microservices Application Programming Interface (API) designs, wherein the one or more candidate microservices API designs are based on at least one of one or more structured data-based files; and
register at least one microservices API design amongst one or more candidate microservices API designs with an API platform, wherein the at least one microservices API design is registered with the API platform for provisioning of an integration interface for integration with one or more environments.

7. The system as claimed in claim 6, wherein the registered microservices API design is specific to the one or more business requirements associated with the user.

8. The system as claimed in claim 6, wherein the one or more candidate microservices API designs comprise at least one of a re-use microservice API design, an enhanced microservice API design, and a new microservices API design.

9. The system as claimed in claim 6, wherein the one or more metadata repositories are queried to render the information based on an associated property file.

10. The system as claimed in claim 6, wherein the one or more touchpoints comprise at least one of one or more system interface touchpoints, one or more API design functional touchpoints, and one or more API design journey touchpoints.