Hello,

On auth0 API specs, there's some fields to pass through the params to return a subset of users : https://auth0.com/docs/api/management/v2#!/Users/get_users

The GetUser method should handle an optional params map to be able to filter the users returned

Opened this issue to tackle the "Use Semver" section of the comment of the issue #14, which was

There are a lot of tools from Vendoring in Go because Google uses monorepo so it's not an issue for them, but recently, an OSS project has the "bless" (not quite yet but) that it may be incorpored on the go tools. This project is dep and you can find the documentatio of how they resolve versioning here.

So basically the other proposal is to add taggs to the repository for versioning. This way we can deprecate the functionality according to the versioning, so in a new major we can remove the /auth0.

Currently some elements of the Call method are not checked:

func (a *Auth0) Call(api_action string, method string, body []byte) ([]byte, error) {
[...]
        _, err := a.client.Get(uri)
        if err != nil {
                return nil, err
        }
[...]
        resp, err := a.client.Do(req)
        if err != nil {
                return nil, err
        }
[...]
        res_body, err := ioutil.ReadAll(resp.Body)
        if err != nil {
                return nil, err
        }

So checks should be added for:

• Client Get
• Client Do
• Read Body

go get github.com/cycloidio/goat throws the following error:
can't load package: package github.com/cycloidio/goat: no buildable Go source files in /Users/darshik/go/src/github.com/cycloidio/goat

I see this API client a bit strange approach of what the README describes.

If it'd be a helper library to call the Auth0 management API, I understand that the API path (e.g. /api/v2) be a parameter, but then having function for calling specific endpoints look strange because those endpoints could change when the path change, for example, between different versions (e.g. /api/v1).

If I consider that this library is a client API for Auth0 management API, I wouldn't:

• make the base URL path (api_version) parameter a loose value, so I would define a constant which define the api version of the client which is instantiated, although at the beginning would be only one.
• export the generic functions:
  • Call(api_action string, method string, body []byte) ([]byte, error)
  • UserCall(method string, user_id string, params map[string]string, body []byte) ([]byte, error)

My rationale behind of currently exposing the Call and UserCall functions is that the library is pretty much work in progress and it doesn't have a function for all the endpoints, however I'm wondering if you have the same rationale and the end goal of this repo is to have a Auth0 client than a generic small wrapper library.

Auth0 jwt access tokens expire after 24 hours so we have to get new ones. Does the library handle this situation?

In issue #12 we updated the documentation to go get github.com/cycloidio/goat/auth0 to install the package.

Now

Basically the problem was that the root of the project does not have any imported code, instead all the code is in /auth0, which is not go friendly.

Proposal

We should move all the code form /auth0 to the root of the package to make the package more consistent and clear with go starndars.
But this proposal involves a bracking change, the import path would no longer be github.com/cycloidio/goat/auth0 so all the projects with this import path will have an import mismatch (if they are updated), because github.com/cycloidio/goat/auth0 will no loger exist. So this proposal brakes COMPATIBILITY.

There are a few things to improve the Makefile:

• Append @ to each shell command which is missing it to avoid to print what's run on the target
• Add the common help target that Cycloid uses
• Change fmt target to use goimports
• Change fmtcheck target to use goimports (It requires to update CI config (.travis.yml)