search

dotnet / aspire

Tools, templates, and packages to accelerate building observable, production-ready apps
https://learn.microsoft.com/dotnet/aspire
MIT License
3.87k stars 463 forks source link

Add basic REST client to Dashboard #964

Open alefranz opened 12 months ago

alefranz commented 12 months ago

When working with APIs, the inner loop could be improved by including in the Dashboard a barebone REST API client. Compared to pointing to the SwaggerUI or using a external tools, would allow to run the API calls and see below the filtered traces and logs related to that transaction. And less alt-tabbing or neck strain! 😅

It would drop the need to always include the Swagger UI in local dev in each API project (and in fact I see the Aspire template doesn't include it)

It should use the .http files as source. It should not try to replace a fully featured REST API client, but focus on covering the basic scenarios.

The new Visual Studio REST API client looks like a webapp so I wonder if maybe it is something the VS team could contribute? 😁 Otherwise, I would be happy to look into it, if there is interest for this addition.

DamianEdwards commented 12 months ago

We've talked briefly about this idea before, so thanks for the suggestion! I can definitely see how it would be useful to have something like the Swagger UI hosted in the dashboard, based on the APIs described by composed resource projects. Initial thoughts are that it's unlikely we'll get to this in v1 so I'll put it on the backlog for now.

samsp-msft commented 11 months ago

AFAIK the swagger UI is a static resource that generates the UI based on the swagger schema definition. That can either be generated dynamically at runtime (the default) or you can have it build a static version at build time.

I suspect that the runtime static swagger generation could be added to the shared project and made conditional on debug/IsDevelopment time flags - I don't know if we'd want to include that as its not applicable to all projects. It's probably better to have it be part of the individual API projects.

The .http file support is making swagger seem somewhat dated - although combining the two to provide swagger-based intellisense in the http file - or writing what API calls were made via the swagger UI to a .http file as some form of output log would be cool.