Investigate sending parameters as json encoded body vs. query string in SDK

[baumatron]

It seems odd that, for example, the event recording portion of the SDK submits events using json, but the analysis requests pack the request parameters into a url-encoded parameter list as part of the request url. Really it makes sense that requests could be done either way, but mixing both ways in the SDK seems unnecessary and probably just adds code and complexity to the SDK.

This usage might have an impact on caching which would be good to consider.

Keen IO API documentation seems to suggest an application/json request body should be used for analyses and doing requests in this way might simplify how requests are done in general across the SDK.

Code such as Queries.KeenWebApiRequest and the methods on Queries that use it could be simplified to make use of Newtonsoft.Json to build the json request body. Going further, code that builds a request across the SDK could be consolidated. There are currently 6 places in the SDK that each create an instance of HttpClient, set authorization headers, make a request, and get the result. I bet there's an opportunity there to get rid of code by creating a common code path. Additionally, guidance for usage of HttpClient is to reuse instances.

[masojus]

I'm sure the theory here originally was that GET is more REST-ful for a query, but we should move to POST so we can have bigger payloads. Locally I've unified the HTTP message dispatching, and then we can later move to generating the payload for queries such that they can be used with Post*() easily, roughly similar to how we handle this in the Java SDK. This would fix Issue #32 of course.

Caching is a good point...we'll have to chat about that.

[masojus]

PHP analogue: keenlabs/KeenClient-PHP#111

[masojus]

Python is headed that way soon, too: keenlabs/KeenClient-Python#130