Rewrote the interfaces of the Splunk object to follow the hierarchy of the Javascript SplunkSDK

[TyMarc]

Based on @aviau 's comment, a wrapper would be better to do better error handling in the future.

Will be used to simplify the creation of a wrapper to generate Promises on top of the JS SDK

[aviau]

Would it make sense to extract this in a SplunkHTTPClient somewhere?

Otherwise we have to copy paste this handler's pointer everywhere?

[TyMarc]

We are actually using the Splunk SDK's HTTP Client, that's why I'm adding the error handling in the Promise directly. Also, the script error handling only apply to the four endpoints we defined in the flare_external_requests script file, not the other HTTP request that are done on the Splunk SDK objects

[aviau]

So then my suggestion is to wrap the Splunk SDK's client?

[TyMarc]

Not sure how I would do that, I'm not working directly with their HTTP client, they already have a wrapper above it to expose their interface, they just append to also have the methods get and post available to do requests with your authentication. The Splunk SDK is injected in the page, it's not a dependency that we have in the project.

[aviau]

Similar to this?:

const splunkClient = () => {
    const post = (url, data) => Promise {
        return promisify(service.post)(url, data).catch(handleHTTPServiceError)
    }
    return {
        post,
    };
}();

[TyMarc]

Got it. It's not a small refactor, I might finish this PR during the cooldown or if I have downtime during the cycle.

[TyMarc]

This PR is now a refactor of the Splunk interface typing on top of the JS SplunkSDK. I will create two other PRs on top of this one: one for the wrapper that will promisify the functions and another one that will actually do the error handling

[markkasaboski]

Does this need to be redeclared here if it's declared in Endpoint that this interface extends from?

[TyMarc]

You're right!

[markkasaboski]

Just the one question. Otherwise, LGTM