|
| 1 | +# **Initial Idea Submission : API Explorer** |
| 2 | + |
| 3 | +**Full Name:** BALASUBRAMANIAM L |
| 4 | +**University Name:** Saveetha Engineering College |
| 5 | +**Program (Degree & Major/Minor):** Bachelor of technology Machine Learning |
| 6 | +**Year:** First year |
| 7 | +**Expected Graduation Date:** 2028 |
| 8 | + |
| 9 | +**Project Title:** API Explorer |
| 10 | +**Relevant Issues:** [https://github.com/foss42/apidash/issues/619](https://github.com/foss42/apidash/issues/619) |
| 11 | + |
| 12 | +## **Project Overview** |
| 13 | + |
| 14 | +Our goal is to enhance API Dash by adding an API Explorer feature. This feature allows users to discover, browse, search, and import pre-configured API endpoints for testing and exploration. All API templates will be maintained in YAML, JSON, HTML, and Markdown formats within a dedicated folder in the existing Apidash GitHub repository. |
| 15 | + |
| 16 | +In the initial phase, contributors can manually add new API definition files (YAML, JSON, HTML, and MD) to the repo, run a local Dart script to process them into structured JSON format, and then commit and push the updated files. A Dart cron job will periodically check for new or modified API files and process them automatically. In the future, we plan to automate this process fully with GitHub Actions. |
| 17 | + |
| 18 | +--- |
| 19 | + |
| 20 | +### **Key Concepts** |
| 21 | + |
| 22 | +- **File Addition:** |
| 23 | + Contributors add new API files (YAML, JSON, HTML, or MD) to a designated folder (`/apis/`) in the Apidash repository. |
| 24 | + |
| 25 | +- **Local Processing:** |
| 26 | + A local Dart script (e.g., `process_apis.dart`) runs to: |
| 27 | + - Read the files. |
| 28 | + - Parse and extract essential API details (title, description, endpoints, etc.). |
| 29 | + - Auto-generate sample payloads when examples are missing. |
| 30 | + - Convert and save the processed data as JSON files in `/api_templates/`. |
| 31 | + |
| 32 | +- **Automated Fetching & Processing with Dart Cron Job:** |
| 33 | + - A Dart cron-like package will schedule the script to fetch and process **new and updated** API files **weekly or on demand**. |
| 34 | + - This reduces the need for constant manual execution and ensures templates stay up to date. |
| 35 | + |
| 36 | +- **Version Control:** |
| 37 | + Contributors create a PR with both the raw YAML files and the generated JSON files to GitHub. |
| 38 | + |
| 39 | +- **Offline Caching with Hive:** |
| 40 | + - The Flutter app (API Explorer) will fetch JSON templates and store them using **Hive**. |
| 41 | + - This ensures **fast loading and offline access**. |
| 42 | + |
| 43 | +- **Fetching Updates via GitHub Releases (ZIP files):** |
| 44 | + - Instead of fetching updates via the GitHub API (which has rate limits), we can leverage **GitHub Releases**. |
| 45 | + - A new release will be created weekly or when at least 10 updates are made. |
| 46 | + - The Flutter app will download and extract the latest ZIP release instead of making multiple API calls. |
| 47 | + |
| 48 | +--- |
| 49 | + |
| 50 | +### **Step-by-Step Workflow** |
| 51 | + |
| 52 | +1. **Adding API Files:** |
| 53 | + - A contributor creates or updates an API file (e.g., `weather.yaml`) in the `/apis/` folder. |
| 54 | + |
| 55 | +2. **Running the Local Processing Script (Manually):** |
| 56 | + - A Dart script (`process_apis.dart`) is executed locally: |
| 57 | + `dart run process_apis.dart` |
| 58 | + - The script: |
| 59 | + - Reads YAML files from `/apis/`. |
| 60 | + - Identifies the file format (YAML, JSON, HTML, MD). |
| 61 | + - Parses the content accordingly. |
| 62 | + - Extracts essential API details (title, description, endpoints, etc.). |
| 63 | + - Generates structured JSON templates in `/api_templates/`. |
| 64 | + |
| 65 | +3. **Review, Commit, and PR Submission:** |
| 66 | + - Contributors review the generated JSON files. |
| 67 | + - They commit both raw API definition files and generated JSON files. |
| 68 | + - Submit a **Pull Request (PR)** for review. |
| 69 | + |
| 70 | +4. **Offline Storage with Hive (Flutter Frontend):** |
| 71 | + - The Flutter app fetches JSON templates and stores them in Hive. |
| 72 | + - This ensures users can access API templates even when offline. |
| 73 | + |
| 74 | +5. **Fetching Updates via GitHub Releases:** |
| 75 | + - A new **GitHub Release** (ZIP) will be created weekly or when at least 10 updates are made. |
| 76 | + - The Flutter app will **download and extract** the latest ZIP instead of making multiple API calls. |
| 77 | + - This approach avoids GitHub API rate limits and ensures a smooth user experience. |
| 78 | + |
| 79 | + |
| 80 | + |
| 81 | + |
| 82 | + |
| 83 | +--- |
| 84 | + |
| 85 | +## **Future Automation with GitHub Actions** |
| 86 | + |
| 87 | +In the future, we can fully automate this process: |
| 88 | + |
| 89 | +- A GitHub Action will trigger on updates to `/apis/`. |
| 90 | +- It will run the Dart processing script automatically. |
| 91 | +- The action will commit the updated JSON templates back to the repository. |
| 92 | +- A GitHub Release will be generated periodically to bundle processed files for easier access. |
| 93 | +- This ensures **continuous and consistent updates** without manual intervention. |
| 94 | + |
| 95 | +--- |
| 96 | + |
| 97 | +## **Conclusion** |
| 98 | + |
| 99 | +This Approach provides a simple and controlled method for processing API definitions. The use of a **Dart cron job** reduces manual effort by fetching and processing updates on a scheduled basis, while **Hive storage** ensures fast offline access in the Flutter app. Using **GitHub Releases (ZIP)** allows fetching updates efficiently without hitting rate limits. Once validated, we can transition to **GitHub Actions** for complete automation. This approach aligns well with our project goals and scalability needs. |
| 100 | + |
| 101 | +**I look forward to your feedback and suggestions on this approach. Thank you!** |
0 commit comments