Crypto-toolbox / bitex

Crypto-currency Exchange API Framework
MIT License
484 stars 136 forks source link

market API version #175

Closed ajeep8 closed 6 years ago

ajeep8 commented 6 years ago

Nils, I had forked bitex and had completed dev branch bitfinex order_book formatter, both v1 and v2, but I wonder if it useful to have both v1 and v2. In BinanceREST you said:

We force version to None here as different endpoints require different versions,

    # so the interface will have to define the version as part of the endpoint.

if you will apply this (define version as part of endpoint) for all market api ?

deepbrook commented 6 years ago

Hey @ajeep8 , Thanks for contributing!

Regarding the version, It depends somewhat on the API and what it offers. For example in Binance, not all endpoints are available on each version, which is why the version needs to be set explicitly in the endpoint method, in order to supply a fully functional interface.

If it is possible, always use a single API version for all methods, and always the latest. I remember implementing both version of bitfinex because there was some functionality missing in V2, which was available in V1 and vice versa. In that case, compare the endpoints - if the majority is available in V2, us that version and program work arounds for the remaining legacy V1 methods.

Does that make sense to you?

ajeep8 commented 6 years ago

I see. So, we should implement only one version in interface and formatters, maybe we need implement 2 versions in api, we should add version into endpoint for other market like binance.

We should not implement 2 versions in interface like inteface/bitfinex.py: def order_book(self, pair, **endpoint_kwargs): """Return the order book for a given pair.""" self.is_supported(pair) if self.REST.version == 'v1': return self.request('book/%s' % pair, params=endpoint_kwargs) prec = endpoint_kwargs.pop('Precision', 'P0') return self.request('book/t%s/%s' % (pair, prec), params=endpoint_kwargs)

Right?

deepbrook commented 6 years ago

You can if you want to, but the priority should be implementing a single, latest API version. In the case above it isnt very complex to support several versions, so that would be ok too.

In essence: if you need to introduce complex hacks to support older versions than the newest available one, do not do so unless it is required to offer the minimal expected functionality of the interface.