Implement POST with get fallback for Query/QueryRange

[jacksontj]

Fixes #428

[jacksontj]

cc @krasi-georgiev

[krasi-georgiev]

Thanks

There are few other places where get is used, should these be updated as well?

do we have a test that ensures this fallback?
I mean ensure that an endpoint that supports only GET uses the GET method and an endpoint that support POST uses the post method.

[jacksontj]

There are few other places where get is used, should these be updated as well?

This does a POST then a GET, so we only want to add this to endpoints we expect POST to work, do we have a list of the ones we want to support fallback on? The change is relatively small, so its easy to add in. As requested in the issue this does simply do a POST and fallback to a GET, there is no control on the client side which method you will use-- this also means if your server only supports GET you'll do a POST then a GET.

do we have a test that ensures this fallback?

From reading the tests, it doesn't seem that anything that actually does this integration test. There are some hard-coded tests that check, but that assumes that the test defines it properly. So I have added a test that the fallback happens as we expect-- which should be sufficient.

[krasi-georgiev]

Thanks, just few small nits.

[jacksontj]

@krasi-georgiev nits addressed :)

[krasi-georgiev]

LGTM after adding all full stops.

@juliusv any notes from you before merging?

[krasi-georgiev]

bummer, failing tests for the different golang versions

[krasi-georgiev]

should also run GO111MODULE=on go mod tidy to update the go.mod file.

[krasi-georgiev]

failing test because of the need to support older golang versions.

api/client_test.go:154: server.Client undefined (type *httptest.Server has no field or method Client)

[beorn7]

httptest.Client has been added in 1.9. If it avoids undue trouble, we could raise the minimum requirement to Go1.9, as we are at Go1.12 already (supporting three versions ought to be enough for everyone). The 1.7 support we still have is essentially because we can.

[jacksontj]

Personally I'd rather bump the required version. But I'll leave that decision up to you maintainers :)

[krasi-georgiev]

yep I think what @beorn7 suggest is ok so can do it as part of this PR or separate one with some details why it was needed.

[beorn7]

I'll prepare a PR. (We can weed out a bunch of code while we are on it.)

[beorn7]

See #561 .

[jacksontj]

@beorn7 @krasi-georgiev rebased with go version change, CI is passing now.

[krasi-georgiev]

Thanks!