beldur/kraken-go-api-client

Allow for custom return structs

Opened this issue · 2 comments

As the API of kraken evolves (new crypto-currencies , response structure etc ... )
It would be helpful for users to be able to define their own response structs.
Currently these are "hidden".
For example in Balance call

// Balance returns all account asset balances
func (api *KrakenAPI) Balance() (*BalanceResponse, error) {
	resp, err := api.queryPrivate("Balance", url.Values{}, &BalanceResponse{})
	if err != nil {
		return nil, err
	}

	return resp.(*BalanceResponse), nil
}

Someone cannot get the balance for 'LINK' for example, because the BalanceResponse struct does not parse this field from the json response.

This method could be more generic, in order to accommodate current (i.e. for LINK) and future needs, without the need for the client to define ALL currencies upfront.

An possible adjustment could be the following :

// Balance returns all account asset balances
func (api *KrakenAPI) Balance(response interface{}) error {
	response, err := api.queryPrivate("Balance", url.Values{}, response)
	if err != nil {
		return err
	}
	return nil
}

I 've made some tests, and it seems to work nicely for the this example of client user code.

type BalanceResponse struct {
	ZEUR  float64 `json:"ZEUR,string"`
	LINK  float64 `json:"LINK,string"`
}

func (api *Remote) Balance() (*BalanceResponse, error) {
	resp := &BalanceResponse{}
	err := api.privateApi.Balance(resp)
	return resp, err
}

and its used as ...

balance, err := client.Api.Balance()

	if err == nil {
		println(fmt.Sprintf("balance = %v", balance.ZEUR))
		println(fmt.Sprintf("balance = %v", balance.LINK))
	}

Would this be an interesting enhancement ? I could look into refactoring corresponding methods in that direction.
And we could always leave the current struct for default use-cases.
What do you think ?

What about just updating BalanceResponse type and add missing assets?

thanks for the reply @Glavic . That would also be an option, for sure.
I personally think that the above is more generic, and there is no need for adjustments on every new currency.