Consider adding a JS/Client based Site Health Check for the REST API

[youknowriad]

Related discussion ​https://wordpress.slack.com/archives/C02RQC26G/p1558429627205600

At the moment, the Site Health Page includes a REST API check that is based on a wp_remote_get call to the posts endpoint.

The problem with this approach is that it only catches issues if they're on the PHP side of things. In the Gutenberg repo, we noticed that there are a lot of issues related to Firewalls... breaking the REST API calls.

The idea here is to consider adding a check to the site health page performing a REST API endpoint call triggered from the client (JS). That way it will go through the regular flow of REST API endpoint calls gutenberg and other clients will use.

[mnelson4]

+1 this, although the code to be changed may send a request to the REST API, the REST API itself shouldn't require any changes, right? Maybe this would fit better into another component?

[desrosj]

Moving Site Health tickets into their lovely new home, the Site Health component.

[TimothyBlynJacobs]

Now that Site Health async tests have been moved to the REST API, #48105, is this still necessary? cc @clorith.

[Clorith]

I don't think this needs any other resolution, no.

With the async tests now being triggered by JS and going through the REST API, and an improvement was also made to JS error handling at the same time, so any failures to use the REST API would be surfaced that way.

There is still the get_test_rest_availability check in Site Health, which could be removed, but at the same time I think it does sort of make sense to leave it in, as you then get both sides of the coin checked out, and I have seen plugins and themes hit up various "local" REST endpoints for whatever reason via PHP code previously, so this would just be an added sanity check for such cases.