Make the path of web endpoints configurable

[wilkinsona]

Many gateways and load balancers ping a URL and just need a 200 back to consider a server to be a candidate for handling requests. We've also heard of teams that "require" this URL to be /health. Given that all they need is a 200 response, the status endpoint is currently the best fit but it's mapped to /status. We should consider making /health provide the rolled up information about the health of the application and making /status provide detailed information.

[snicoll]

So the argument is about the size of the body? IMO it feels weird that something named status returns the full information while health returns only something named "status".

[wilkinsona]

No, I think it's more an argument about security. If we leave things as they are and a load balancer requires the use of /health then the balancer either has to authenticate or you have to open up all of the information exposed by /health to everyone.

[snicoll]

OK but let's keep #8685 on the radar. If we do this, we'd offer /status/{name} rather than /health/{name}. Given the structure of the reply and what a "status" is vs. what "health" means, it looks completely backwards to me.

[philwebb]

I think /health is the more common URL so perhaps that should be the one reveals the least. I'd also be quite keen on bringing the names closer together. How about /heath and /healthdetails ?

[snicoll]

If we want to do that, we have no choice IMO, status should go away and should be renamed to something that states it provides additional details. It is a shame because I think the current names are just about right (I am not a huge fan of /healthdetails and an HealhDetailsEndpoint), this
constraint of having the existing endpoint showing only the status is messing things up :(

Can we reconsider perhaps? We want to use 2.0 to fix things and I believe this is one of them.

[wilkinsona]

@snicoll What do you want to reconsider?

[bclozel]

Agree, both /status and /health names are right and logically we should just swap them. But this will a real problem for environments running both Spring Boot 1.x and 2.x.

So my vote goes to /status going away and keeping /health for the basic information. As for the additional endpoint, /healthdetails is not perfect, but at least it gives you the impression that you'll get "more of the same"; which is exactly what we're trying to do.

I'm still nervous about moving things there; we're basically making a backwards incompatible change not for the load-balancers, but for the APMs using that endpoint to get the details.

[snicoll]

Reconsider swapping them. The naming is right now IMO so I'd really like to keep things as they are now.

[philwebb]

Since we're pretty much all agreed that /application/status and /application/health are logical paths, perhaps we should fix the "problem" a different way? Can we re-instate the ability to change the paths that endpoints are mapped to? It doesn't need to be in properties, perhaps a strategy bean that the user can register?

[wilkinsona]

I don't even think it would be so bad if we supported it via the properties now, particularly if we moved them beneath web to make it clear that JMX was unaffected: endpoints.<id>.web.path.

We definitely don't want to reintroduce support for changing the ID which had the side-effect of changing the path.

[snicoll]

This isn't my preferred option as well. Hopefully systems can adapt over time to /status.

[wilkinsona]

@snicoll Did you mean this is my preferred option?