Health Score iCall - Dynamic Modification of a Pool Member's Ratio

The primary reason for querying individual server by it's FQDN is if you input host name site address then big ip on the control plane would resolve that FQDN (such as f5.domain.com) likely back to the VIP address created using sharepoint 2013 iApp and as such would be load balanced back to the exact pool you are trying to dynamically determine/modify ratio for and as such be unable to perform a "per server" health score check. This should not be an issue because the whole goal is to retrieve back a response that contains the X-SharePointHealthScore header, which does not require using a public-facing FQDN and the recommendation when using this iApp (and even the current design built into 2016 iApp) is to create a "sharepoint web app" with anonymous auth enabled using a specific port and point the URL in this healthscore iapp to use that. Now I agree that this limits the per sharepoint web application health score monitoring, but if you look at the metrics used to determine score...they are system metrics such that any specific web application health score header returned would match any other web application hosted on that specific server.