[APM] Ensure correct encoding of body in callApi

[dgieselaar]

Fixes issue with the ML and Watcher integrations where the body ended up being encoded to JSON twice. Introduced in 06bee60.

[sorenlouv]

Why should bodies in GET requests not be stringified?

btw. What do you think about a small rename:

Suggested change

	const bodyObject = isGet
	const bodyObject = isGetRequest

[dgieselaar]

AFAIR, body is not allowed in GET requests per NP requirements. All of this is to work around schema limitations, so hopefully we can get rid of it when #50179 is addressed.

[sorenlouv]

AFAIR, body is not allowed in GET requests per NP requirements

In that case we'll never send body with GET requests, right? So having this check won't matter afaict.

[sorenlouv]

Eg. we could always just JSON.stringify(body) afaict - or will that cause validation issues?

[dgieselaar]

I might not be understanding what you mean. This code adds { body: { ... } } to all non-GET requests (either empty or whatever it was given). We need at least an empty body value to pass the current NP request validation. Do you see a way we can do this without checking the request method?

[sorenlouv]

I was thinking something like this. So not depending in the http verb but only whether there is a body or not:

  return {
    ...rest,
    ...(fetchOptions.body ? JSON.stringify(body) : {}),
    query: {
      ...fetchOptions.query,
      ...(debugEnabled ? { _debug: true } : {})
    }

But if NP requires a body for all requests then that's not possible (although that sounds like an odd requirement)

[elasticmachine]

💚 Build Succeeded

• continuous-integration/kibana-ci/pull-request
• Commit: dcb2fc06e2a1f2bee295d4570943c691c060ca4a

[elasticmachine]

💚 Build Succeeded

• continuous-integration/kibana-ci/pull-request
• Commit: d2f6c34

[dgieselaar]

Going to close this in favor of an incoming PR that addresses some other issues as well.