[Feat]: Make `A2ARouteBuilderExtensions` path parameter optional

[cdavernas]

Is your feature request related to a problem? Please describe.

No response

Describe the solution you'd like

To make the path parameters of the A2ARouteBuilderExtensions optional, defaulting to /.

Describe alternatives you've considered

No response

Additional context

No response

Code of Conduct

• I agree to follow this project's Code of Conduct

Note

If you’re using the current API, please share:

Your typical route patterns

• Whether a default / would reduce boilerplate for you
• Any edge cases where an implicit default could introduce ambiguity

Your feedback will help us choose a sensible, least‑surprising default. Thanks!

[rokonec]

@cdavernas Can you please describe your use case?

[cdavernas]

@rokonec The primary motivation is to reduce redundancy—since in 99% of cases the / path will be used—while also making the codebase more concise, esthetic, and aligned with established .NET conventions.

Although this isn’t a critical requirement, I believe that consistency, readability, and overall "look & feel" play an important role in the quality of an official library. This expectation is even stronger here, given that the library is largely driven by Microsoft personnel, where adherence to .NET idioms and developer experience are generally considered core values.

[rokonec]

Thank you for your suggestion! While I understand the idea of defaulting the path parameter to "/", I respectfully disagree with making "/" the default in most cases.

From my experience, the root path "/" is commonly reserved for landing pages, health checks, or documentation endpoints, rather than being used for specific json-rpc methods. Best practice typically suggests using "/" for endpoints that provide general information about the service or application.

Could you share more about your reasoning for using "/" as a default? I’m open to discussing alternative defaults or approaches that align with established conventions.

[cdavernas]

Thank you for sharing your perspective! I completely understand your point about / typically being reserved for landing pages, health checks, or documentation endpoints. That’s a very common and sensible convention.

In my case, I personally only provide an A2A API to my agents, so I’ve been considering / as the natural default — similar to how MCP servers use /. That said, you’re right that it was presumptuous for me to suggest it as the default in most cases. We might indeed need to define a more ubiquitous default endpoint that avoids conflicting with established practices. Something like /a2a could maybe strike a better balance.

I’d be happy to continue the discussion and explore which option would best serve both general conventions and agent-specific APIs.

[rokonec]

We’ll keep this issue open for now. Before making the path parameter optional with a default of /, we’d like to observe more real-world usage and gather community input on what the most helpful default behavior would be (e.g., /, empty, or explicit-only).

If you’re using the current API, please share:

Your typical route patterns

• Whether a default / would reduce boilerplate for you
• Any edge cases where an implicit default could introduce ambiguity
• Your feedback will help us choose a sensible, least‑surprising default. Thanks!

Let me know if you’d like a shorter or more formal version