[Feature Request]: Enhance REST API Gateway to Support Form Data, Path Parameters, and Dynamic Path Variables

[caochenlei]

🧭 Type of Feature

Enhancement to existing functionality

🧭 Epic

Title: Enhance REST API Gateway to Support Form Data, Path Parameters, and Dynamic Path Variables

Goal: Enable the MCP-compliant REST API gateway to fully support common HTTP request patterns including multipart/form-data, application/x-www-form-urlencoded, path parameters (e.g., /users/{id}), and dynamic routing with variable substitution.

Why now: As more tools and services expose functionality via REST APIs that use form-encoded data or dynamic paths, the current limitation prevents seamless integration. Developers and integrators benefit from reduced boilerplate code and improved compatibility with real-world APIs.

---

🙋♂️ User Story 1

As a: Integration Developer

I want: To invoke REST endpoints that accept form-data or x-www-form-urlencoded request bodies

So that: I can integrate with third-party services (e.g., authentication providers, file upload APIs) that require form-encoded input.

✅ Acceptance Criteria

Scenario: Invoke API with form-encoded data
  Given a REST tool is configured with method POST and content-type "application/x-www-form-urlencoded"
  When a request is made with form fields (e.g., grant_type=password&username=alice&password=secret)
  Then the request body should be correctly encoded as form data
  And the Content-Type header should be set to "application/x-www-form-urlencoded"

Scenario: Upload file using multipart/form-data
  Given a REST tool is configured to send multipart form data
  When a request includes both text fields and binary file attachments
  Then the payload should be properly serialized as multipart MIME
  And each part should have correct Content-Type and headers

---

🙋♂️ User Story 2

As a: API Consumer

I want: To define API routes with path variables (e.g., /api/v1/users/{userId}) and pass dynamic values at runtime

So that: I can reuse the same API definition for different resource IDs without duplicating configurations.

✅ Acceptance Criteria

Scenario: Resolve path variable in route
  Given an API endpoint defined as "/orders/{orderId}/status"
  When the client calls it with orderId = "ORD-12345"
  Then the resolved URL should be "/orders/ORD-12345/status"
  And the variable should be substituted before sending the request

Scenario: Handle multiple path variables
  Given an API endpoint: "/orgs/{orgId}/teams/{teamId}/members"
  When called with orgId="IBM", teamId="DEV01"
  Then the final URL should be "/orgs/IBM/teams/DEV01/members"

---

📐 Design Sketch (optional)

Just like below, it can be flexibly controlled and fully supports open APIs

---

🔗 MCP Standards Check

Change adheres to current MCP specifications No breaking changes to existing MCP-compliant integrations If deviations exist, please describe them below: None. This is a backward-compatible enhancement.

---

🔄 Alternatives Considered

Pre-processing in client logic

Workaround: Manually construct URLs and serialize form data in client code.

Rejected: Increases complexity, violates DRY, not scalable. Use custom middleware/proxy

Workaround: Deploy a reverse proxy to normalize requests.

Rejected: Adds operational overhead and latency. Convert all APIs to JSON-only wrappers

Rejected: Not feasible for external APIs controlled by third parties.

---

📓 Additional Context

Include related issues, links to discussions, issues, etc.