Design di API RESTful e Integrazione WebSocket

REST mappa il CRUD su HTTP: GET per le letture, POST per creare, PATCH per aggiornamenti parziali, DELETE per rimuovere. Usa i codici di stato onestamente — un 200 con un JSON di errore rompe i client.

Versiona nel path (/v1/), pagina le liste grandi (feed a cursore per stream append-only), e documenta i breaking change con una finestra di deprecazione.

Le API key identificano; i secret provano. Per gli endpoint di trading, applica HMAC a una stringa canonica (metodo + path + body + timestamp) così che il secret non viaggi mai sulla rete. Rifiuta i timestamp obsoleti per bloccare i replay — ±30s è una finestra comune.

OAuth si adatta alle app di terze parti; i bot puri per exchange restano spesso su chiave+HMAC. Rate limit: aspettati 429 e onora Retry-After.

La sessione inizia come un HTTP GET con Upgrade: websocket; il server restituisce 101 Switching Protocols. Dopo, i frame sono economici rispetto agli handshake TLS ripetuti su un polling HTTP.

I messaggi di subscribe sono di solito JSON: metodo, canali, e talvolta firme di autenticazione per i fill privati.

Lo stream dei trade è dato tick; i book sono snapshot + delta con numeri di sequenza. Se perdi delle sequenze, ri-sincronizza da uno snapshot REST e poi applica i delta con sequenza > snapshot.

Heartbeat: invia ping o aspettati ping dal server; riconnetti con backoff jitterato per evitare thundering herd.

GraphQL riduce l'over-fetching per le dashboard; molti exchange esporano ancora REST per i percorsi caldi del trading. Le specifiche OpenAPI (Swagger) aiutano codegen e QA — mantieni gli esempi copiabili e riutilizzabili.

Esegui il loop WebSocket in un task, spingi gli ultimi prezzi in una mappa thread-safe, esponi HTTP per gli health check. Logga i conteggi di riconnessione; allerta quando aumentano.