After completing #13, you'll need to create API endpoints so our front-end app is able to inquire balances, transactions and status orders for a given user.
The order history endpoint should accept a start_date parameter that will be used as filter. If that parameter is informed in the request, then only the orders placed/created after that date will be fetched.
We'll need 3 endpoints here - OpenOrders, TradeHistory, Balances
As input parameter, the endpoints will receive start and end dates, except for balance, that should receive only a single date parameter (to ask for a balance in a given time)
One extra param we'll call "force_reload". False by default. When true, instead of fetching the most recent data we have for the user and exchange, we will use XChange to fetch at that time the most recent orders or transactions (don't forget to update the last_updated data field in the userExchange DB entry after a successful collection - see comments in #13 about this)
The user will be identified by a token. For now, assume e fixed user, until we develop the authentication logic
In terms of response, the endpoints will return a JSON containing in the first level a list of exchanges that contain data for the given user
The data within each exchange object will be basically a JSON representation of XChange objects - OpenOrder's, UserTrade's or balance pairs (coin, value), depending on the endpoint
After completing #13, you'll need to create API endpoints so our front-end app is able to inquire balances, transactions and status orders for a given user.
The order history endpoint should accept a start_date parameter that will be used as filter. If that parameter is informed in the request, then only the orders placed/created after that date will be fetched.