Open MarcoK80 opened 5 years ago
If they are exposed by the aspnetcore api explorer then you should just see them, otherwise it would require some manual code, eg an additional document processor which looks them up and adds them as new operations
Tested with NSWag Studio and ASP.NET Core via API Explorer and it seems the healthcheck routes defined in the startup are not exposed via aspnetcore api explorer.
So this is always only a single operation with a simple route (eg /health) and GET?
Yes correct. We try to get this manual in. Seems more an issue for Microsoft to have these kind of APIs available in the api explorer.
Not sure if it makes sense to include that for all users - not everyone might want this to end up in the spec. Should probably opt-in via explorer settings. /cc @pranavkm any plans to do this?
@rynowak \ glencc, what do you guys think? The current contract with Swagger generator is integrated with MVC, we may have to come up with something different if we want to consider this.
We have no plans to do this in ASP.NET Core 3.0. This is possible for someone else to provide with extensibility, either:
IApiDescriptionProvider
Endpoint Routing (ASP.NET Core 3.0+) is a good foundation to build OpenAPI on top of, it's much more information/metadata rich than middleware. I want the community to have an OpenAPI story that's endpoint-centric eventually, but it's not clear what work that requires from us and when we would slot that in. We're much more focused now on getting users of MVC onto the new routing system as a primary concern.
I would be really interested to see what it would look like for a framework like NSwag or Swashbuckle to integrate directly with the endpoint collection.
We have no plans to do this in ASP.NET Core 3.0. This is possible for someone else to provide with extensibility, either:
- by integrating the global endpoint collection directly with NSwag/Swashbuckle through their extensiblity
- by implementing an
IApiDescriptionProvider
Endpoint Routing (ASP.NET Core 3.0+) is a good foundation to build OpenAPI on top of, it's much more information/metadata rich than middleware. I want the community to have an OpenAPI story that's endpoint-centric eventually, but it's not clear what work that requires from us and when we would slot that in. We're much more focused now on getting users of MVC onto the new routing system as a primary concern.
I would be really interested to see what it would look like for a framework like NSwag or Swashbuckle to integrate directly with the endpoint collection.
Hi,
So we have just stumbled across this issue with health checks not being exposed.
I've seen the work around involving adding a proxy controller and it feels hacky and requires effort at every touch point.
I liked the idea of using a Document filter within swagger hooks, felt more open close.
However the more I read the more this feels like the problem lies with default IApiDescriptionProvider and actually of that returned the health check then the rest would just 'work'.
Currently working on trying to add a new HealthCheckDescriptionProvider that adds just that with lower priority than the default.
Can anyone see any issues with this plan?
Appreciate any guidance thanks
Currently working on trying to add a new HealthCheckDescriptionProvider that adds just that with lower priority than the default.
I think this should work, ie a decorator around the original description provider which passes everything through and adds another operation for the health endpoint
Microsoft offered the possibility to have Healthcheck endpoints directly in the startup > https://docs.microsoft.com/de-de/aspnet/core/host-and-deploy/health-checks?view=aspnetcore-2.2 If we want to include this Healthcheck APIs in the generated swagger is there a way with NSwag to achieve this?