|
| 1 | +### Initial Idea Submission |
| 2 | + |
| 3 | +Full Name: Avinav Verma |
| 4 | +University name: Indian Institute of Information Technology and Management (ABV-IIITM), Gwalior |
| 5 | +Program you are enrolled in (Degree & Major/Minor): Integrated IT + MBA |
| 6 | +Year: 3rd Year |
| 7 | +Expected graduation date: June 2028 |
| 8 | + |
| 9 | +Project Title: API Automation & Workflow Builder for API Dash |
| 10 | + |
| 11 | +Relevant issues: |
| 12 | +- Related to API Explorer concept |
| 13 | + |
| 14 | +--- |
| 15 | + |
| 16 | +## Idea Description |
| 17 | + |
| 18 | +API Dash provides a convenient interface for testing APIs and managing requests. With the proposed **API Explorer**, developers will be able to discover and import public APIs into their workspace. However, real-world API usage often involves more than sending a single request. Developers frequently need to authenticate with multiple services, reuse credentials, chain API calls together, and automate repetitive interactions. |
| 19 | + |
| 20 | +This proposal introduces an **API Automation & Workflow Builder** for API Dash. The goal is to extend API Dash from a simple API testing tool into a lightweight platform for building and automating multi-step API workflows. |
| 21 | + |
| 22 | +The system will allow developers to visually construct API pipelines where the output of one API request can be used as the input for another. It will also provide centralized credential management and automatic handling of authentication tokens, making API interactions easier and more efficient. |
| 23 | + |
| 24 | +--- |
| 25 | + |
| 26 | +## Key Features |
| 27 | + |
| 28 | +### 1. Credential Manager |
| 29 | +Many APIs require authentication using API keys, OAuth tokens, or client credentials. Currently, developers must manually configure these credentials for each request. |
| 30 | + |
| 31 | +The proposed credential manager will allow users to securely store authentication information and reuse it across multiple API requests. This reduces repeated configuration and improves organization when working with several services. |
| 32 | + |
| 33 | + |
| 34 | +**Support for Multiple Profiles** |
| 35 | + |
| 36 | +The credential manager will support multiple user profiles or environments. |
| 37 | +Each profile can maintain its own set of API credentials, tokens, and configuration variables. |
| 38 | + |
| 39 | +For example, a developer may maintain separate profiles for: |
| 40 | + |
| 41 | +• Personal projects |
| 42 | +• Work environments |
| 43 | +• Testing or sandbox APIs |
| 44 | + |
| 45 | +Switching between profiles will automatically apply the appropriate credentials to API requests and workflows. This allows developers to test integrations across different environments without repeatedly reconfiguring authentication details. |
| 46 | + |
| 47 | +--- |
| 48 | + |
| 49 | +### 2. Automatic Token Refresh |
| 50 | +Many APIs issue temporary tokens that expire after a fixed time interval. When a token expires, the user must manually request a new one before continuing. |
| 51 | + |
| 52 | +The system will automatically detect expired tokens and call the appropriate refresh endpoint when necessary. The new token will be stored and used automatically for subsequent requests, preventing interruptions in API workflows. |
| 53 | + |
| 54 | +**Edge Case Handling:** |
| 55 | +* **Expired Refresh Tokens:** If the refresh token itself expires or is revoked, the system will pause the workflow and elegantly prompt the user to re-authenticate rather than failing silently or looping infinitely. |
| 56 | +* **Network Interruptions:** If a refresh fails due to a network timeout, the engine will implement a standard exponential backoff retry mechanism before marking the workflow step as failed. |
| 57 | + |
| 58 | + |
| 59 | + |
| 60 | +--- |
| 61 | + |
| 62 | +### 3. API Workflow Chaining |
| 63 | +Developers often need to combine multiple APIs to complete a task. For example: |
| 64 | + |
| 65 | +Weather API → AI summarization API → Notification API |
| 66 | + |
| 67 | +Instead of manually copying responses between requests, API Dash will allow users to build workflows where the output of one API call becomes the input of the next. To achieve this cleanly, users will be able to utilize **JSONPath** expressions to extract specific data points from a JSON response body and map them to the headers, query parameters, or body of the subsequent request. |
| 68 | + |
| 69 | +While the initial iteration will focus on linear workflows, the architecture will be designed with the future possibility of **Basic Control Flow** (e.g., executing different requests based on a successful 200 vs a 404 response). |
| 70 | + |
| 71 | + |
| 72 | + |
| 73 | +--- |
| 74 | + |
| 75 | +### 4. Visual Workflow Builder |
| 76 | +A visual interface will allow users to create API workflows using drag-and-drop components. Each block will represent an API request, and arrows between blocks will represent the flow of data. |
| 77 | + |
| 78 | +Users will be able to define how outputs from one request map to inputs of another. Internally, these workflows will be stored as structured JSON configurations and executed by a workflow engine. |
| 79 | + |
| 80 | + |
| 81 | + |
| 82 | +--- |
| 83 | + |
| 84 | +### 5. Exporting & Sharing Workflows |
| 85 | +Because workflows are stored internally as structured JSON files, developers will be able to easily export, import, and share their pipeline configurations. This makes API Dash a highly collaborative tool, allowing teams to share complex integration tests or staging environments effortlessly. |
| 86 | + |
| 87 | +--- |
| 88 | + |
| 89 | +## Implementation Approach & Technical Architecture |
| 90 | + |
| 91 | +The feature will be implemented natively in Dart as an extension to API Dash's existing Flutter architecture. |
| 92 | + |
| 93 | +1. **Credential Manager Module:** Handles secure, encrypted storage of API keys and tokens locally using Flutter's secure storage solutions. |
| 94 | +2. **Workflow Execution Engine:** A background Dart service that parses the JSON workflow configurations. It executes API requests sequentially, utilizes JSONPath for data extraction and mapping, and handles asynchronous errors. |
| 95 | +3. **Token Refresh Handler:** An interceptor integrated into the HTTP client that detects 401 Unauthorized responses, triggers the refresh logic, and queues pending requests until the new token is secured. |
| 96 | +4. **Workflow Builder Interface (UI):** Building a visual node-editor requires careful Flutter state management and efficient rendering (such as `CustomPaint` for the node connections). Constructing the drag-and-drop pipeline will involve utilizing `StatefulWidget`s effectively to ensure that the state of complex interactive elements (like draggable nodes and resizable layout dividers) is perfectly preserved across UI rebuilds without degrading canvas performance. |
| 97 | + |
| 98 | +Each workflow will be stored internally as a structured configuration that defines: |
| 99 | +- The sequence of API calls |
| 100 | +- How outputs map to inputs |
| 101 | +- Authentication details for each step |
| 102 | + |
| 103 | +--- |
| 104 | + |
| 105 | +## Possible Development Plan |
| 106 | + |
| 107 | +* **Phase 1: Community Bonding & Planning:** Familiarize myself deeply with the API Dash codebase, refine the JSON schema for workflow configurations, and discuss the optimal state management approach for the visual builder with mentors. |
| 108 | +* **Phase 2: Credential Management & Token Handling:** Implement secure local storage for credentials, build the UI for adding/editing API keys, and develop the HTTP interceptor logic to handle 401 errors and automatic token refreshing. |
| 109 | +* **Phase 3: Workflow Engine Core:** Build the Dart engine capable of parsing the workflow JSON, executing sequential requests, and mapping response data to subsequent inputs. |
| 110 | +* **Phase 4: Visual Workflow Builder UI:** Develop the interactive Flutter UI. Focus on the drag-and-drop canvas, node connections, and ensuring state is preserved cleanly during complex user interactions. |
| 111 | +* **Phase 5: Integration & Error Handling:** Connect the visual builder UI to the execution engine. Implement clear visual feedback for successful steps and errors within the UI. |
| 112 | +* **Phase 6: Testing & Documentation:** Finalize unit and widget tests, write comprehensive user documentation, and prepare the final pull request. |
| 113 | + |
| 114 | +--- |
| 115 | + |
| 116 | +## Expected Benefits |
| 117 | + |
| 118 | +This feature expands API Dash beyond simple request testing and provides a powerful environment for experimenting with API integrations. |
| 119 | + |
| 120 | +Developers will be able to: |
| 121 | +- build multi-step API workflows |
| 122 | +- reuse authentication credentials |
| 123 | +- automate API interactions |
| 124 | +- test complex API integrations more efficiently |
| 125 | + |
| 126 | +Overall, this will improve developer productivity and make API Dash a more versatile tool for API exploration and automation. |
0 commit comments