Feature request: History API

[lispc]

trafficstars

Depends https://github.com/Fluidex/dingir-exchange/issues/5

REST API list:

• get all recent trades of a market
• get my recent trades of a market
• get my closed/inactive/finished orders ( both filled and canceled) of a market [1]
• get my open/active/pending orders( will be redirect to the matching server ) of a market [2][3]

[1]: JWT auth can be skipped now. Will add it later. [2]: This is a quite interesting API design. Binance has an API get all my orders both active and inactive while CoinEx separates these two types of orders CoinEx finished order API and CoinEx pending order API. Is CoinEx API not sufficient for algo traders? I don't know. At least we can implement 'get all my orders' by merging 'get all my open orders' and 'get all my closed orders' and then if we find one order is both in 'open orders' and 'closed orders' ( inconsistency ), we just treat 'closed' as truth. [3]: In Binance API, you can query active/inactive orders on one specified market or on all markets, but you can only query inactive orders on one specified market. Even, their doc said "Get all open orders on a symbol. Careful when accessing this with no symbol. Weight: 1 for a single symbol; 40 when the symbol parameter is omitted", putting a "penalty" for "get all my open orders" query, I guess it is due to that they have to query all the shareds ( shared by market )? Meanwhile, there seems no 'get all my open orders' API for CoinEx, which I think may be insufficient for UX?

[noel2004]

Question: I guess an order can become inactive just at the same time we reply it as an active one under a query. And this issue will not be a case the server should consider ?

[lispc]

Question: I guess an order can become inactive just at the same time we reply it as an active one under a query. And this issue will not be a case the server should consider ?

I think it is inevitable. Users should know when they get a response and the response said one order was open, it means "was open" rather than "is open now".

[noel2004]

My opinion:

1. I guess trader may be much interested in the opened orders then the closed one. So they may expect a series of API to just query the open orders with less latency (and better SLA?)

2. I also guess it should be good to persisted the order in db when the order is just put and by doing that we are in fact have another API to query all orders (both opened and closed), which just querying from db, with larger latency, and maybe some more limitations (less quota or more expensive, etc.)

[0xmountaintop]

Question: I guess an order can become inactive just at the same time we reply it as an active one under a query. And this issue will not be a case the server should consider ?

I think it is inevitable. Users should know when they get a response and the response said one order was open, it means "was open" rather than "is open now".

timestamp and msg_id are for that purpose

[0xmountaintop]

At least we can implement 'get all my orders' by merging 'get all my open orders' and 'get all my closed orders'

One thing we need to be careful about when merging is pagination.

Say if we sort by time. We need to decide how many records we select from open_orders and from closed_orders before merging. I guess we can assume a user probably won't open 10 orders at the same time for each symbol.

[0xmountaintop]

I guess trader may be much interested in the opened orders then the closed one

I totally agree.

by doing that we are in fact have another API to query all orders

Yeah the way we handle "hotspot" APIs and "non-hotspot" APIs should be different. And just a reminder: this should still be seamless to users -- users don't need to care about whether we use persistant storage for an API.

[0xmountaintop]

Framework: actix-web? ( We need to implement websocket stuff later, actix-web is a good choice for this )

Yes actix-web seems the top option for now, in terms of

• async
• HTTPS
• WS
• Middleware
• speed
• github stars / activities

References:

• https://github.com/flosse/rust-web-framework-comparison
• https://64.github.io/actix/
• https://dev.to/readredready/state-of-rust-web-frameworks-server-3g42