REST API: String argument for rest_do_request/rest_ensure_request does not work as expected.

[TimothyBlynJacobs]

According to the rest_do_request() php docs, a string parameter type is accepted. Currently, this is forwarded to rest_ensure_request() which only accepts a WP_REST_Request object or an array. When a string argument is passed a request object is instantiated with a string value for the request attributes which is improper.

Either the docs should be updated, or, ideally, the rest_do_request and rest_ensure_request functions would be updated.

I could see those two functions either accepting a route path, like /wp/v2/posts or a full url, www.example.org/wp-json/wp/v2. Since those API functions are internal to the API instance, it makes most sense, in my mind at least, to accept a path style argument. Otherwise, there would be needless boiler plate: rest_do_request( rest_url( '/wp/v2/posts' ) ).

The simplest implementation would then be to instantiate a WP_REST_Request object with the given path as the second constructor argument if the $request parameter is a string. However, this would make it impossible to quickly make a request with any query parameters attached.

That gives us a few options.

1. Change rest_ensure_request to do WP_Rest_Request::from_url( rest_url( $request ) ) in case of a string argument.
2. Introduce WP_Rest_Request::from_path that accepts a path and does the proper parse_url and wp_parse_str handling.
3. Only accept a full URL to rest_do_request.

If it might be confusing that rest_ensure_request accepts a path argument instead of a URL, conceivably it could accept both and switch on the presence of a / at the start of the string.

Happy to submit a patch to whichever makes most sense.

[rmccue]

Hmm, I wonder how this happened, maybe we changed rest_ensure_request() at some point, because the idea of that function was to do just this. In any case, I think it's too late to change it.

I'd prefer to do the simple thing here and treat a string parameter as a route with no further parsing (that is, directly instantiate WP_REST_Request). More advanced usage can continue to create a WP_REST_Request manually; I'd rather not have rest_do_request() turn into an everything-and-the-kitchen-sink function. Alternatively, we could remove the string capability altogether and treat this as a docs bug.

[TimothyBlynJacobs]

Patch added to treat a string argument as a request path.

[kadamwhite]

Seems like good low-hanging fruit to pull in for 5.3

[spacedmonkey]

This patch needs a simple unit test

[kadamwhite]

Introduce a basic unit test for this feature

[kadamwhite]

Change redundant test docbloc to a @ticket annotation

[kadamwhite]

In 46099:

REST API: Accept string path in rest_ensure_request.

Update rest_ensure_request() to accept a string path, permitting a string path to be passed to rest_do_request() as is indicated (previously inaccurately) in that method's PHPDoc.

Props TimothyBlynJacobs, kadamwhite.
Fixes #40614.