Add ExecutingResponseCreator to delegate request and response

[simonbasle]

This commit adds a new convenience ResponseCreator implementation that
delegates to a ClientHttpRequestFactory to perform a request and
use the response.

For further convenience, a factory method based on a RestTemplate is
also added: MockRestResponseCreators#byExecutingRequestUsing. This
acts as a pseudo-DSL for fluently setting the ResponseCreator in a
ResponseActions.

The primary purpose of this implementation is to perform an actual
request to an external service and use the response in MockMVC.

Closes gh-26381

[rstoyanchev]

Thanks for putting this together based on the discussion under #26381. Looking at the result, I'm wondering if it wouldn't be more idiomatic to simply provide a ResponseCreator implementation instead:

public class ExecutingResponseCreator implements ResponseCreator {

	private final ClientHttpRequestFactory requestFactory;


	public ExecutingResponseCreator(RestTemplate restTemplate) {
		this.requestFactory = restTemplate.getRequestFactory();
	}


	@Override
	public ClientHttpResponse createResponse(ClientHttpRequest request) throws IOException {
		Assert.state(request instanceof MockClientHttpRequest, "Expected mock request");
		MockClientHttpRequest mockRequest = (MockClientHttpRequest) request;
		ClientHttpRequest newRequest = this.requestFactory.createRequest(mockRequest.getURI(), mockRequest.getMethod());
		newRequest.getHeaders().putAll(mockRequest.getHeaders());
		StreamUtils.copy(mockRequest.getBodyAsBytes(), newRequest.getBody());
		return newRequest.execute();
	}
}

which is then used:

ResponseCreator executingResponseCreator = new ExecutingResponseCreator(restTemplate);
MockRestServiceServer server = MockRestServiceServer.bindTo(restTemplate).build();
...
server.expect(requestTo("/foo")).andRespond(withSuccess());
server.expect(requestTo("/bar")).andRespond(executingResponseCreator);

The rest of the code, MockRestServiceServer, ResponseActions, RequestExpectationManager implementations would remain unaware of any of this, which simplifies the implementation, and is generally easier to understand how it fits.

It would provide extra flexibility too because it becomes just another ResponseCreator that's no different from the rest. I'm thinking, we could provide an option for setting a default ResponseCreator in the MockRestServiceServer builder. That's independently useful, but if set to the ExecutingResponseCreator it would execute requests by default when andResponse isn't called. That's the effect that was sought in the original comment under #26381.

[simonbasle]

@rstoyanchev I have reverted the previous implementation and introduced ExecutingResponseCreator instead per your suggestion.

[simonbasle]

mmh I realize just now that the factory method in MockRestResponseCreators doesn't make much sense, because the ExecutingResponseCreator MUST be instantiated early on, before the RestTemplate's factory is changed...

I wonder how to improve the discoverability of the feature 🤔

[rstoyanchev]

Thanks that looks very nice and simple.

For the visibility, we could:

• add a paragraph in the Javadoc for MockRestResponseCreator that links to the alternative ExecutingResponseCreator along with an @see reference.
• add something in the reference docs under this section.
• yet another option is to add a sample test to the ones mentioned here, and that could use MockWebServer like in WebClientIntegrationTests for example