Initial Idea Submission : API Explorer

[BalaSubramaniam12007]

PR Description

Initial Ideation: API Explorer for Apidash

This PR outlines the initial ideation and approach for implementing an API Explorer in Apidash.
The goal of this feature is to allow users to discover, browse, search, and import pre-configured API endpoints for testing and exploration.

What This PR Covers

Project Overview

• Enhancing API Dash with an API Explorer for seamless API discovery.
• Maintaining API templates in multiple formats (YAML, JSON, HTML, and Markdown).

Proposed Approach

1. File Addition: Contributors add API definition files (/apis/) in YAML, JSON, HTML, or MD formats.
2. Local Processing Script (process_apis.dart):
   • Detects file type and parses API details (title, description, endpoints, payloads).
   • Converts everything into a structured JSON template (/api_templates/).
3. Automated Updates via Dart Cron Job (Future):
   • Automates API file processing periodically.
   • Future integration with GitHub Actions for full automation.
4. Offline Storage (Hive):
   • API templates stored locally for fast access & offline usability.
5. Fetching Updates via GitHub Releases (ZIP files):

Future Plans & Next Steps

• Automate Processing & Deployment (GitHub Actions).
• Integrate UI Components for API Explorer in API Dash.

---

This PR serves as the foundation for the API Explorer project . Would love to get feedback and insights from mentors !

UI implementation will be addressed in future PRs—this PR focuses only on getting workflow suggestions.

Related Issues

• API Explorer #619

Checklist

• I have gone through the contributing guide
• I have updated my branch and synced it with project main branch before making this PR
• I am using the latest Flutter stable branch (run flutter upgrade and verify)
• I have run the tests (flutter test) and all tests are passing

Added/updated tests?

We encourage you to add relevant test cases.

• Yes
• No,

OS on which you have developed and tested the feature?

• macOS
• Windows
• Linux

[BalaSubramaniam12007]

@ashitaprasad @DenserMeerkat I’ve put together an initial approach for API Explorer project and would appreciate your feedback.
Could you please review it and let me know if it aligns with the project needs? Any suggestions for improvement would be greatly valued.

Looking forward to your insights !

[ashitaprasad]

This gives some idea for the backend, but currently lacks frontend design.
Also, pick a sample api & provide a sample for the file that will reside in apis folder and what will be the structure of api_template for that API.

[BalaSubramaniam12007]

@ashitaprasad
I have created a sample wireframe outlining the API selection, details, and testing workflow. UI LINK

I have chosen the OpenAI API as a sample API. Below is the sample structure of how an API definition file will be stored in /apis/openai.yaml

name: OpenAI API
description: API for interacting with OpenAI models.
base_url: https://api.openai.com/v1
endpoints:
  - path: /completions
    method: POST
    description: Generate text based on a given prompt.
    headers:
      - Authorization: Bearer <YOUR_API_KEY>
      - Content-Type: application/json
    request_body:
      model: text-davinci-003
      prompt: "Translate this into French: 'Hello, how are you?'"
      max_tokens: 50

And how the processed JSON template will be structured in /api_templates/openai.json

{
  "name": "OpenAI API",
  "description": "API for interacting with OpenAI models.",
  "base_url": "https://api.openai.com/v1",
  "endpoints": [
    {
      "path": "/completions",
      "method": "POST",
      "description": "Generate text based on a given prompt.",
      "headers": {
        "Authorization": "Bearer <YOUR_API_KEY>",
        "Content-Type": "application/json"
      },
      "request_body": {
        "model": "text-davinci-003",
        "prompt": "Translate this into French: 'Hello, how are you?'",
        "max_tokens": 50
      }
    }
  ]
}

This sample was generated with AI assistance to demonstrate the format.

The JSON follows a pretty format for better readability and uses a nesting technique to maintain structured relationships between data fields . Let me know if you’d like any modifications or suggestions on improving the design and structure of the templates !

[ashitaprasad]

@BalaSubramaniam12007 The wireframe looks cool.
The processed file is currently not compatible with our request model.

[BalaSubramaniam12007]

@ashitaprasad Thank you for your feedback on the wireframe! I'm continuing to refine the design to ensure a smooth user experience.

Regarding the processed file, could you clarify what aspects are incompatible with the request model? Are there specific structural changes or missing fields that need to be addressed? If there's a preferred format or example, I'd be happy to align the output accordingly.

Looking forward to your guidance!

[BalaSubramaniam12007]

Ma’am, after reviewing the RequestModel structure, here’s what I observed:

Our current RequestModel handles requests by defining a structured format, but there are differences in how it processes URL structure, HTTP methods, headers, body, and query parameters compared to processed JSON format. Below is a comparison:

Aspect	** Processed JSON**	RequestModel
URL Structure	"base_url" + "path"	url (single string)
Method	"method": "POST" (string)	method: HTTPVerb.post (enum)
Headers	[{"key": "Authorization", "value": "Bearer ..."}]	headers: List<NameValueModel>
Body	{"type": "json", "content": { "key": "value" }}	body: String (JSON String)

Do you mean by this, ma’am? Am I on the right track? 😊

[ashitaprasad]

Ma’am, after reviewing the RequestModel structure, here’s what I observed:

Our current RequestModel handles requests by defining a structured format, but there are differences in how it processes URL structure, HTTP methods, headers, body, and query parameters compared to processed JSON format. Below is a comparison:

Aspect ** Processed JSON** RequestModel
URL Structure "base_url" + "path" url (single string)
Method "method": "POST" (string) method: HTTPVerb.post (enum)
Headers [{"key": "Authorization", "value": "Bearer ..."}] headers: List<NameValueModel>
Body {"type": "json", "content": { "key": "value" }} body: String (JSON String)
Do you mean by this, ma’am? Am I on the right track? 😊

You are on the right track.

Basically, when the user clicks "try now" -> you should be able to quickly create the Request from the JSON

[BalaSubramaniam12007]

Ma’am, after reviewing the RequestModel structure, here’s what I observed:
Our current RequestModel handles requests by defining a structured format, but there are differences in how it processes URL structure, HTTP methods, headers, body, and query parameters compared to processed JSON format. Below is a comparison:
Aspect ** Processed JSON** RequestModel
URL Structure "base_url" + "path" url (single string)
Method "method": "POST" (string) method: HTTPVerb.post (enum)
Headers [{"key": "Authorization", "value": "Bearer ..."}] headers: List<NameValueModel>
Body {"type": "json", "content": { "key": "value" }} body: String (JSON String)
Do you mean by this, ma’am? Am I on the right track? 😊

You are on the right track.

Basically, when the user clicks "try now" -> you should be able to quickly create the Request from the JSON

Thank you for the confirmation, ma’am. My approach aligns with the same concept, and I have also referenced it in the wireframe sketch.

[ashitaprasad]

@BalaSubramaniam12007 Time to work on and send across a PR as notified in the discord server.

[animator]

@BalaSubramaniam12007 Can you kindly submit the draft proposal for review.

[BalaSubramaniam12007]

@animator @ashitaprasad Thanks for having patience. I prepared an optimized solution with future expandability, I planned to be a part of this beyond the gsoc. This solution solves #121 too, with the foundation for #502.

I would like to share my draft GSoC Proposal for API EXPLORER.
Your feedback would be greatly appreciated. Thank you for your time.

[animator]

@BalaSubramaniam12007 Follow the application guidelines provided here - #564 like all other GSoC participants and submit PR for application review.

[BalaSubramaniam12007]

@animator Thanks for the guidance, sir! I've submitted a PR #744 proposal following the guidelines in #564. Please let me know if any changes are needed. Looking forward to your feedback!