Open ycrumeyrolle opened 7 years ago
Related to this and #9, we have talked about this.
Our current thinking is that the default middleware will not do auth, nor expose information, precisely because there will be consumers of the endpoint that may not support auth and really don't care about the data (just the 200/5xx). For users who want a more feature-rich endpoint, we will encourage (and add the sample) the idea of a protected endpoint which returns full data. Using the controller then allows the full gamut of endpoint protection.
/cc @glennc
This is what I have called a canary endpoint at issue #13. Canary endpoint for health checks, responding 200/5XX, useful for load balancer. Healthcheck endpoint for detailed health checks, useful for web monitoring. Require to be protected.
To achieve this we are thinking that you accept the IHealthCheckService in a controller and use MVC. It is trivial to do in a controller and gives you full control.
What if I do not want to rely on MVC ? It is also trivial to do this in a middleware :)
I would like to not rely on MVC because this kind of components may be exposed by all applications in my scope. Developers are able to override MVC default behavior, bringing to unexpected errors. ie. default JSON format is CamelCase and a developer replace it by the snake_case format.
There's nothing stopping someone from providing more full-featured middleware as a third party extension.
The healthcheck middleware may expose the following informations :
Exposing such informations allow to a monitoring tool to aggregate health of the application over the time.