Add support for Oauth based requests and Google Analytics Account Listing

[elkelk]

This adds the ability to define an oauth_only binding on a method which will bypass key usage. It also adds an implementation of Google Analytics Accounts listing.

This is the first of a couple methods that I'll need. More PRs will probably follow filling out some of the other google analytics methods I'll be using.

[elkelk]

I went ahead and added the google analytics web properties methods to this as well.

[elkelk]

I'm considering changing the return values for all functions. I (and others) will need to get at the status codes. An elixir-like approach that would retain the body being returned would be to have the methods return {:ok, body} in the successful case and {:error, response} in any sort of failure. The only ambiguity with this approach is determining what an ok response is: any 2xx or just 200?

Any insight would be appreciated.

[seanabrahams]

@elkelk Thanks for the PR!

Changing the return values will be a breaking change so if we end up doing that it should definitely be thought through. That said, it makes sense to make the request results (other than body) accessible. Some options include:

1. Return {:ok, body} or {:error, response} as you noted
2. Return the request results in their entirety, so get!(URI.encode_query(params)) instead of get!(URI.encode_query(params)).body which will return an httpoison response:

%HTTPoison.Response{
  body: "{\n  \"args\": {},\n  \"headers\": {} ...",
  headers: [{"Connection", "keep-alive"}, {"Server", "Cowboy"},
  {"Date", "Sat, 06 Jun 2015 03:52:13 GMT"}, {"Content-Length", "495"},
  {"Content-Type", "application/json"}, {"Via", "1.1 vegur"}],
  status_code: 200
}

3. Add a configuration option that will return the request results in their entirety when provided, otherwise keep the same behavior
4. Add a function parameter that, when true, will return the request results in their entirety
5. Create our own Response data type

I was initially inclined to go with #2 making this library a simple wrapper around httpoison, however this has the disadvantage of coupling to that library which is making me think #1 or #5 may be the way to go in case we ever want to switch out httpoison for something else.

We could do {:ok, response} and {:error, response} to make the response code accessible.

[elkelk]

@seanabrahams thanks for the quick reply. I'm good with most of these. I had considered #2, and I don't think it's too dangerous to rely on HTTPoison. #5 solves the dependency issue, but it feels like we'd be reinventing the wheel.

If you are heavily opinionated in any direction, I'm happy to follow that path.

[elkelk]

I've updated the PR taking approach number 1:

Return {:ok, body} or {:error, response}

We should consider creating releases so that breaking changes won't affect clients that rely on a different return format.

[seanabrahams]

Cool, what did you end up doing regarding status codes on successful requests? Not important? Let's cut a release once this PR is ready to go 👍

[elkelk]

I just return the body in the case that status code is in the 2xx range. If it's ever an issue in the future we can revisit, but I can't really see it being a problem.

This should be good to go, although I'm considering adding some tests. Give me a couple days to look into that, and I'll post when the merge is ready.

Thanks for responding, BTW. So many PRs I've posted on projects just sit in limbo. 💯

[seanabrahams]

Gotcha. I don't yet have a use-case for needing the 2xx status codes. Appreciate you taking the charge on it. Tests sound even better :-) Thanks for submitting PRs!

[elkelk]

I've added tests under the analytics modules using exvcr. We can probably pretty quickly test the other api methods, but I didn't have time to setup my google account with those apis yet, and exvcr let's you record the http requests directly.

Of note, you can run mix vcr.check to see whether a "cassette" or a server call is used for a particular test.

I'm going to add more methods under Google.Apis.Analytics.Views, but feel free to merge before then if you are ok with everything.