Is your feature request related to a problem?

In a project I'm working on, I have some integration tests that are testing some code that relies on the functions of the opensearchapi package. However, when it's time to assert that the output is equal to the expectations, it's not possible to write a simple require.Equal(t, wantResp, resp) because the response object returned by the client includes the response *opensearch.Response field, which is hard to predict.

What solution would you like?

The solution I propose is to return the HTTP response as second return value, instead of inside the API response object. In this way, SomeResp becomes somewhat predictable, as it would no longer contain a field whose value is unknown until the request is actually made. In this way, code like the one below is possible without much effort:

resp, err := s.opensearchClient.SomeFunc(context.Background(), SomeReq{
	// Params
})

want := &elastic_types.SomeResp{
	// Expected values
}

require.NoError(t, err)
require.Equal(t, want, resp)

Roughly, the changes would be these ones:

type SomeResp struct {
-	response *opensearch.Response
}

-func (c *Client) SomeFunc(ctx context.Context, req SomeReq) (*SomeResp, error) {
+func (c *Client) SomeFunc(ctx context.Context, req SomeReq) (*SomeResp, *opensearch.Response, error) {
	var (
		data SomeResp
-		err  error
	)

-	if data.response, err = c.do(ctx, req, &data); err != nil {
+	resp, err := c.do(ctx, req, &data)
+	if err != nil {
-		return &data, err
+		return nil, resp, err
+	}

-	return &data, nil
+	return &data, resp, nil
}

What alternatives have you considered?

An alternative solution might be to compare each field of the response object separately. However, this doesn't scale well when there are a lot of fields and makes the code longer and harder to read and maintain.

Do you have any additional context?

As this is a breaking change, the downside is that it might take quite some time to be released. I would also be open to contribute this change myself, if accepted.