Simplify auto-discovery process

[kadamwhite]

@rmccue notes that appending ?rest_route=/ to a WordPress URL will yield the root response JSON (e.g. make.wordpress.org/core/?rest_route=/)—this is simpler than trusting to the presence of a header or an HTML <link> element, and we can use the self relation for the root API route to determine that base URL.

[rmccue]

Here's how I'm doing discovery FWIW.

[luisherranz]

@kadamwhite @rmccue we ran into this problem as well.

We work with a lot of WordPress installations from different customers and a lot of them strip the Link header (usually because of some cache service) and others simply return 404 on the /wp-json endpoint. We've always used the ?rest_route=/ query to access the API and had much better success with it.

Besides, the current implementation of autodiscover has an extra roundtrip, which slows down both the server side rendering and the client initilization.

All this is at no extra benefit when you already know the correct WP-API endpoint.

So, would you please accept a PR to accept "endpoint" urls on the autodiscovery initilization?

It could be something like this:

// Works with normal urls, so it's backwards compatible:
const wpapi = await WPAPI.discover( 'https://make.wordpress.org/core' );
// But if the url contains ?rest_route=, we avoid the headers request:
const wpapi = await WPAPI.discover( 'https://make.wordpress.org/core/?rest_route=/' );

What do you think?