Våra API:er erbjuder ett sätt att programmatiskt interagera med våra plattformar, men båda plattformarna erbjuder två olika gränssnitt: på Spot, REST och WebSocket (v1 och v2), och på Futures tillhandahålls även både REST- och WebSocket-API:er. Ibland kan det vara ett svårt beslut att välja det mest lämpliga gränssnittet för en specifik uppgift.
På Spot, medan båda tillhandahåller exakt samma marknadsdata (orderböcker, handelshistorik, etc.) och exakt samma kontodata (kontosaldon, order-/handelsstatus, etc.), gör REST och WebSocket detta på betydligt olika sätt.
REST erbjuder ett gränssnitt av typen anrop/svar (fråga/svar) och ger en ögonblicksbild av aktuell data, medan WebSocket erbjuder ett gränssnitt av typen livestreaming och ger uppdateringar i realtid.
En analogi skulle vara skillnaden mellan ett fotografi och en video, där ett fotografi på begäran ger en ögonblicksbild av motivet men inga ytterligare uppdateringar, medan en video ger en realtidsvy av motivet med livestreaming-uppdateringar.
Även om varken REST eller WebSocket är svåra att implementera, är det allmänt accepterat att REST är mindre komplext, vilket gör att utvecklingstiden kan minskas och eventuella efterföljande problem kan lösas snabbare.
REST baseras på standardiserade HTTPS-förfrågningar som ingår i standardbiblioteken för alla moderna programmeringsspråk (och skulle lätt kunna kodas från grunden om inte), medan WebSocket baseras på en WSS-uppgradering från HTTPS som vanligtvis kräver ytterligare tredjepartsbibliotek (som vårt rekommenderade WebSocket-bibliotek för Python).
Våra API-supportsidor tillhandahåller färdiga exempelkoder för både REST och WebSocket, därför kan valet av gränssnitt göras med mer kritiska kriterier snarare än enkel implementering.
Beroende på uppgiften kan antingen endast REST, endast WebSocket, eller mer sannolikt en kombination av både REST och WebSocket vara det optimala valet.
För uppgifter som endast kräver enstaka uppdateringar av marknadsdata skulle REST vara det föredragna valet. Till exempel skulle en bot för daglig kostnadsgenomsnittning som endast behövde marknadsdata en gång var 24:e timme inte ha något behov av realtidsströmning av marknadsdata, varför REST-marknadsdata-slutpunkterna skulle vara mer än lämpliga.
För uppgifter som krävde den mest uppdaterade marknadsdata som fanns tillgänglig, skulle WebSocket vara det föredragna valet. Till exempel skulle en arbitragebot behöva realtidsmarknadsdata från flera marknader för att kunna dra nytta av tillfälliga prisskillnader, varför WebSocket-marknadsdataflödena skulle vara det idealiska valet.
I de flesta fall (som majoriteten av handelsbotar) skulle en kombination av REST och WebSocket möjliggöra den mest effektiva implementeringen. Till exempel kan en mobilapp kräva realtidsmarknadsdata för sina diagram, samtidigt som den endast behöver kontodata ibland (när den till exempel gör en handel eller en finansieringstransaktion), varför användning av WebSocket-marknadsdataflöden tillsammans med REST-slutpunkterna för order-/handels-/finansieringsstatus skulle vara den mest effektiva kombinationen.
Vårt API-supportteam diskuterar gärna din API-implementering med dig och ger förslag på det optimala sättet att använda vårt API baserat på ditt avsedda användningsscenario.