Open MelchiSalins opened 4 years ago
Hi @MelchiSalins
Thanks for your feedback.
I think you are referring to our old WebSocket API.
If you are starting to develop please can you use the latest version below: https://api.btcmarkets.net/doc/v3#tag/WS_Overview
Thanks.
Regards, Martin
I'm developing on v3 as well. The body looks something like this.
{ "marketId": "XLM-AUD", "timestamp": "2020-06-10T00:17:26.987Z", "bestBid": "0.1119", "bestAsk": "0.1133", "lastPrice": "0.1118", "volume24h": "83174.81793818", "messageType": "tick", "price24h": "-0.0031", "low24h": "0.1115", "high24h": "0.1159", "snapshotId": 1591748246987000 }
Would be great if it would look something like this
>{
"messageType":"tick",
"timestamp": "2020-06-10T00:17:26.987Z",
snapshotId": 1591748246987000,
"data":{
"marketId": "XLM-AUD",
"bestBid": "0.1119",
"bestAsk": "0.1133",
"price24h": "-0.0031",
"low24h": "0.1115",
"high24h": "0.1159",
}
}
This makes it more efficient to work with strongly typed languages such as Golang. Casting the incoming message to the right struct currently is extremely inefficient because of the body structure. Probably something to keep in mind for the v4?
We try to design WebSocket messages to be as similar as possible to REST API responses hence where possible we will keep the same flat json structure.
I'm hoping every programming language offers efficient deserialization of the flat json structure for the WebSocket (and also REST API ) messages/responses.
Thanks for the suggestion anyway.
Would be great if socket data looked something like this:
All the channels subscribed should have an Event field to denote the type of message it is. Currently its completely up to the consumer to make sense of the data returned which is not efficient at all.