API REST istantanea per database SQL popolari — senza condividere le credenziali.
Trasforma qualsiasi query SQL salvata in un endpoint REST pronto per i partner, con chiavi API per destinatario, quote di byte mensili e una traccia di controllo completa. Statico o in streaming, JSON, NDJSON o CSV, compressione LZ4 in tempo reale: tutto senza infrastruttura da ospitare e senza esporre codice SQL al destinatario.
Chiedi a Nova, ottieni SQL + grafici
Incontrare Nova
Una chiave per ogni partner. Nessuna credenziale condivisa.
Creare un'API
+più
Sincronizzazione programmata con oltre 6 piattaforme
Esplorare
+più
Interrogare le API con SQL, senza codice
Esplorare
+più
Claude, Cursor, ChatGPT e Grok interagiscono con i tuoi dati
Connetti l'IAQuery Streams è una piattaforma di integrazione dati sicura e in tempo reale che trasforma qualsiasi query SQL salvata in un endpoint API REST pronto per i partner, con chiavi per destinatario, quote di byte mensili e una traccia di controllo completa. La piattaforma API consente di condividere dati di database in tempo reale con clienti, fornitori e team interni senza mai dover divulgare credenziali di accesso al database, codice SQL o topologia di rete. Per saperne di più, visita QueryStreams.com e iscriviti gratuitamente Per creare la tua prima API condivisa in cinque minuti.
Condividi i dati del database in tempo reale tramite API REST, senza condividere le credenziali.
La maggior parte dei team invia esportazioni CSV, distribuisce account di database di sola lettura o configura un servizio Express personalizzato quando un partner ha bisogno di dati in tempo reale. Ogni approccio presenta lo stesso problema: il partner finisce per avere qualcosa che non dovrebbe avere, ovvero una casella di posta piena di CSV obsoleti, una credenziale SQL che sopravvive a lungo dopo la fine del progetto o l'accesso root a un servizio che nessuno gestisce attivamente. La piattaforma API Query Streams consente di condividere i dati in tempo reale. capacità di eseguire una query salvataNon le credenziali sottostanti. Ogni destinatario riceve la propria chiave API, ogni chiamata è soggetta a limitazioni di frequenza e a verifiche, e l'accesso può essere revocato dal Portale con un solo clic, senza dover modificare alcuna password del database.
Chiavi API per destinatario
Ogni destinatario riceve il proprio qsapi_* Chiave. Revoca una senza toccare le altre. Ruota senza ridistribuire nulla.
Le credenziali non lasciano mai la tua rete
L'agente di rete effettua una connessione dal tuo ambiente. Il destinatario visualizza un endpoint REST, mai il nome host del tuo database, la password o le istruzioni SQL.
Sola lettura per impostazione predefinita
Il meccanismo di controllo in sola lettura dell'agente rifiuta qualsiasi istruzione diversa da SELECT prima che raggiunga il database. Non esiste un percorso di "cancellazione accidentale".
Modalità di risposta statica e in streaming
Scegli tra un singolo corpo bufferizzato (8 MB / 100.000 righe predefinite) o un trasferimento a blocchi che invia le righe man mano che l'agente le produce (1 GB / 10 milioni di righe predefinite).
LZ4-frame + compressione del filo gzip
Modalità payload opzionale LZ4-frame per i consumatori SDK (decompressione in una riga), oltre allo standard Accept-Encoding: gzip sui percorsi non compressi.
Sandbox in stile postino integrata
Testa ogni endpoint all'interno del Portale prima di condividerlo. Modifica i parametri della query, ispeziona il JSON, copia il arricciare — nessuna area di lavoro Postman separata.
CORS + liste di indirizzi IP consentiti
Associa la chiave di un destinatario a specifici indirizzi IP o CIDR, limita l'origine del browser per endpoint e applica i limiti di velocità standard a due livelli.
Specifiche OpenAPI 3.1 per endpoint
Ogni endpoint espone un formato leggibile dalla macchina openapi.json. Dagli da mangiare a Postman, Swagger UI o a un generatore di SDK come openapi-typescript.
Sono supportati i database SQL più diffusi.
La piattaforma API funziona con i database SQL che la maggior parte dei team già utilizza. Una volta connesso il tuo Network Agent, ogni query salvata su un database supportato può essere promossa a un endpoint REST condiviso, senza necessità di configurazione o SDK specifici per ogni database.
I database ospitati nel cloud funzionano allo stesso modo
L'agente si connette in modo altrettanto efficace sia ai database locali che ai servizi gestiti come AWS RDS, Azure SQL Database, Google Cloud SQL e Snowflake. Per ottenere la latenza migliore, è consigliabile distribuire l'agente nella stessa area geografica del database; un singolo account Query Streams può eseguire più agenti in diverse aree geografiche e cloud.
Come funziona in tre fasi
Una volta configurati l'agente di rete e un connettore di database supportato, la promozione di una query salvata a un'API condivisa richiede circa cinque minuti:
Salva una query SQL
Crea la query nel Generatore di query del portale per qualsiasi database connesso. Aggiungi filtri, parametri e un nome. Tutto ciò che puoi selezionare è accessibile tramite API.
Promuovilo come API
Apri la scheda Installa. Scegli un tipo di endpoint (permanente, a scadenza o con budget di chiamate N-shot), un formato interno (JSON, NDJSON o CSV), una modalità di risposta (statica o in streaming) e se è consentita la compressione LZ4. Salva.
Invita i destinatari tramite e-mail
Inserisci l'indirizzo email di un partner; riceverà un invito di attivazione tramite un link magico. I destinatari sprovvisti di un account Query Streams otterranno un'organizzazione gratuita creata automaticamente al momento dell'attivazione: la loro chiave verrà rilasciata non appena accetteranno.
Utilizzate già Query Streams per Excel o Fogli Google?
Quindi il tuo Network Agent è già in posizione e il tuo database è già connesso. La promozione di una query salvata esistente a un endpoint REST richiede circa un minuto: salti i passaggi 1 e la maggior parte del passaggio 2. La stessa query salvata può alimentare un aggiornamento di Excel, una barra laterale di Fogli, e un endpoint REST rivolto al partner allo stesso tempo.
Scegli una modalità di risposta: statica o in streaming
Ogni endpoint, al momento della creazione, sceglie una delle due modalità di risposta. La modalità controlla il modo in cui i byte lasciano i nostri server; il formato di trasmissione (JSON, NDJSON, CSV o frame LZ4) viene scelto autonomamente dal destinatario per ogni singola chiamata.
L'impostazione predefinita. Raccogliamo ogni riga in un'unica risposta bufferizzata, impostata Lunghezza del contenutoe emettono un corpo. Gli errori sono normali codici di stato HTTP (200, 400, 413 API_OUTPUT_TOO_LARGE, 503).
- Limiti predefiniti: 8 MB / 100.000 righe per chiamata
- Piattaforma massima: 50 MB / 1.000.000 di righe per chiamata
- Ideale per: dashboard, ricerche su richiesta, query con meno di 10.000 righe, curl, strumenti di intelligenza artificiale che richiedono un singolo blob JSON
Noi torniamo 200 OK + Transfer-Encoding: chunked Non appena arriva la prima riga, le righe successive vengono inoltrate lungo la rete man mano che l'agente le produce. La memoria ai margini della rete rimane limitata indipendentemente dalle dimensioni del risultato.
- Limiti predefiniti: 1 GB / 10.000.000 di righe per chiamata
- Piattaforma massima: 50 GB / 100.000.000 righe per chiamata
- Ideale per: Flussi n8n/Zapier, pipeline di analisi, esportazioni in blocco, qualsiasi cosa che tragga vantaggio dal tempo di risposta del primo byte
Gli errori a metà flusso su un endpoint di streaming non possono essere espressi come codice di stato HTTP (lo stato è già stato inviato con il primo blocco). Li visualizziamo come ultimo record sentinella: {"_error":"...","righe_restituite":N} per NDJSON, o # errore: ..., righe_restituite: N per lo streaming CSV. Le librerie client dovrebbero controllare l'ultimo record prima di considerare lo streaming completo.
Scegli un formato di trasmissione: JSON, NDJSON, CSV o LZ4-frame
All'interno della modalità di risposta scelta, i destinatari selezionano il formato di trasmissione per ogni chiamata utilizzando le intestazioni HTTP standard (Accettare per il formato interno e Codifica di accettazione (per la compressione). Un endpoint può supportare tutti e quattro i formati; il proprietario può anche bloccare l'endpoint su un singolo formato dalla scheda Installa.
Un singolo array JSON. Formato predefinito per la modalità statica. Il formato universale per client web, strumenti di intelligenza artificiale e utenti curl.
# Python dati = richieste.get(url, intestazioni=h).json()
JSON delimitato da interruzioni di riga, una riga per riga. Solo streaming. Analisi in tempo reale per pipeline ed ETL.
# Python per linea In resp.iter_lines(): riga = json.loads(linea)
CSV conforme a RFC 4180. Funziona sia in formato statico (corpo unico) che in streaming (intestazione nel primo blocco). Aprilo con Excel, pandas, R o qualsiasi altro programma in grado di leggere file CSV.
# panda
df = pd.read_csv(url, storage_options=h)
Il formato frame LZ4 conforme agli standard (magico) 04 22 4D 18Un frame per i contenuti statici; frame concatenati tramite trasferimento a blocchi per lo streaming. Fatture su byte compressi.
# Python
dati = lz4.frame.decompress(resp.content)
Per i consumatori che desiderano la massima interoperabilità, il semplice JSON (o CSV) è sufficiente: tutto il resto è facoltativo. La compressione dei dati (gzip) si sovrappone automaticamente ai percorsi non compressi tramite lo standard Codifica di accettazione intestazione; non effettuiamo mai una doppia compressione, quindi LZ4-frame sostituisce gzip anziché sovrapporsi ad esso.
Le quattro combinazioni di fili in sintesi
La modalità di risposta e la compressione del payload si compongono in quattro percorsi foglia. Il proprietario dell'endpoint sceglie le impostazioni predefinite nella scheda Installa; il destinatario può sovrascriverle per ogni chiamata (entro i limiti consentiti dal proprietario). Compressione del flusso (gzip) negoziata tramite Codifica di accettazione strati sopra le due righe non compresse automaticamente.
Un singolo buffer applicazione/json (o testo/csv) corpo con Lunghezza del contenutoPercorso predefinito. Compressione dei dati (gzip) negoziata automaticamente.
Un singolo applicazione/frame x-lz4 Corpo contenente un frame LZ4 standard (multiblocco). Decompressione in una riga di codice client.
applicazione/x-ndjson (o streaming) testo/csv) Sopra Transfer-Encoding: chunkedUna riga per blocco. Compressione dei dati (gzip) negoziata automaticamente.
applicazione/frame x-lz4 come sequenza di frame LZ4 standard concatenati tramite trasferimento a blocchi. Nessun protocollo di framing inventato da QS.
| Modalità + compressione | Tipo MIME del filo | Forma del corpo | Limiti predefiniti | Bollette su | Caso d'uso |
|---|---|---|---|---|---|
| statico + nessuno | applicazione/json o testo/csv |
Un corpo bufferizzato, Lunghezza del contenuto |
8 MB / 100.000 righe | byte non compressi | Dashboard, curl, predefinito |
| statico + lz4 | applicazione/frame x-lz4 |
Telaio singolo LZ4 (multiblocco) | 8 MB compressi | byte compressi | Consumatori SDK, risposta singola ottimizzata in termini di costi |
| flusso + nessuno | applicazione/x-ndjson o testo/csv |
Trasferimento a blocchi, NDJSON per riga | 1 GB / 10 milioni di righe | byte non compressi | n8n, Zapier, pipeline di analisi |
| streaming + lz4 | applicazione/frame x-lz4 |
Trasferimento a blocchi, frame LZ4 concatenati | 1 GB compresso (circa 5 GB non compressi) | byte compressi | Esportazione in blocco, SDK per utenti esperti, la combinazione più economica e veloce |
Passa i filtri al momento della chiamata
Qualsiasi parametro di query salvato esposto dal proprietario può essere impostato dal destinatario a ogni chiamata. OTTENERE le richieste utilizzano la stringa di query; INVIARE Le richieste utilizzano un corpo JSON. L'agente associa i parametri come valori di prepared statement appropriati, mai come concatenazione di stringhe, in modo che il destinatario non possa uscire da un parametro per iniettare codice SQL.
Il proprietario dell'endpoint controlla quali parametri vengono esposti (nella sottoscheda Parametri della scheda Installa), quali sono bloccati su un valore fisso e qual è l'insieme di valori consentiti. I destinatari possono impostare solo i parametri esposti dal proprietario; tutto il resto è fisso. I parametri multivalore utilizzano chiavi ripetute (?status=pagato&status=spedito) su GET e un array JSON standard su POST.
Stato di sicurezza: CORS, liste IP consentite e limiti di velocità
Oltre alle chiavi per singolo destinatario e all'applicazione dell'autorizzazione di sola lettura, ogni endpoint offre quattro ulteriori misure di sicurezza che è possibile rafforzare prima di condividerlo.
Elenco IP consentiti per chiave
Associa la chiave di un destinatario a un singolo IP, a un intervallo CIDR o a un elenco. Supporta sia IPv4 che IPv6. Una chiamata dall'esterno della lista consentita restituisce 403 IP_NON_CONSENTITO prima che venga modificato l'SQL.
Elenco di utenti CORS consentiti per endpoint
Indicaci quali origini del browser sono autorizzate a chiamare l'endpoint da JavaScript. Imposta ["https://app.acme.com"] per un singolo partner, oppure disattivare completamente CORS (impostazione predefinita) per endpoint solo server-to-server.
Limiti tariffari a due livelli
Un bucket di token sulla chiave del destinatario (predefinito 60 richieste/min) più un secondo bucket sull'endpoint stesso (predefinito 120/min). Un destinatario rumoroso non può esaurire il budget per quelli ben educati.
Quote mensili di byte
Limite facoltativo per endpoint sui byte fatturati al mese. Quando viene raggiunto il limite, le chiamate vengono restituite 429 ENDPOINT_QUOTA_ESAURITA fino al ripristino del periodo. Un limite di raggio d'esplosione sicuro per i nuovi partner.
Ogni endpoint viene fornito con una specifica OpenAPI 3.1
Ogni endpoint espone una specifica leggibile dalla macchina a GET /v1/endpoints/{id}/openapi.jsonDescrive l'URL, il metodo, ogni parametro (con tipo, valori consentiti, valore predefinito), ogni struttura di risposta per formato (JSON, NDJSON, CSV, frame LZ4) e ogni codice di errore. Incollalo in Postman o Insomnia per generare una raccolta di richieste, inseriscilo in Swagger UI per ottenere documentazione interattiva oppure elaboralo tramite un generatore SDK per ottenere un client tipizzato nel linguaggio di programmazione che preferisci.
Utilizzalo da Power BI, Tableau e qualsiasi strumento JSON.
Poiché ogni endpoint restituisce standard JSON — con CSV e NDJSON in streaming — qualsiasi strumento in grado di leggere un feed REST consuma i dati direttamente, senza bisogno di installare nulla sul lato del destinatario. Power Query è il ponte più semplice per entrare nello stack di Business Intelligence di Microsoft: in Power BI scegliere Ottieni dati → Dal Web, incolla l'URL dell'endpoint, aggiungi il Autorizzazione intestazione e Power Query analizza il JSON in una tabella aggiornabile che alimenta il modello di dati. (Per i dati in tempo reale all'interno di un foglio di calcolo, il nativo Componenti aggiuntivi Query Streams per Excel e Fogli Google sono la strada più semplice: Power Query è disponibile quando si desidera accedere ai dati direttamente nel modello di BI.
Power Query
Ottieni dati → Dal Web, incolla l'URL e il token bearer, espandi il JSON in una tabella aggiornabile
Power BI
Stesso motore Power Query: carica l'endpoint nel tuo modello e pianifica l'aggiornamento.
Tableau
Punta un connettore dati Web o un'origine JSON all'endpoint per dashboard in tempo reale
Postino
Importa le specifiche OpenAPI 3.1, quindi invia, analizza e condividi le richieste con un solo clic.
Si nutre anche n8n, Qlik, arricciare, Python (richieste o pandas.read_json), Insomnia, Hoppscotch — o qualsiasi script o flusso di lavoro in grado di inviare una richiesta HTTP e leggere JSON.
Verifica gli endpoint direttamente nel tuo browser, in stile Postman, senza uscire dal Portale.
Prima di consegnare una chiave a un partner, esegui tu stesso l'endpoint. La scheda Installa include un generatore di richieste integrato che replica ciò che vedrà il destinatario: seleziona il metodo HTTP, imposta i parametri di query, scegli un esempio, invia la richiesta e controlla la risposta. La sandbox utilizza una chiave temporanea, quindi la chiamata segue esattamente lo stesso percorso di una richiesta del destinatario: stessa autenticazione, stesso invio dell'agente, stessa negoziazione della compressione, stesso conteggio dei byte.
Fatturazione con compensazione della compressione
Il conteggio dei byte nel registro delle attività è misurato all'uscita del nostro server API e seguire una regola semplice e prevedibile: se il destinatario ha acconsentito Compressione del carico utile del frame LZ4 (Accept-Encoding: lz4), le bollette delle chiamate sui byte compressi che sono effettivamente passati attraverso la linea; altrimenti, le bollette delle chiamate sui byte non compressi. Compressione standard della linea HTTP (gzip) è pura ottimizzazione del trasporto e non influisce sulla fatturazione: la compressione avviene dopo che abbiamo misurato i byte che il consumatore è tenuto a "visualizzare".
Nota sui byte trasmessi via cavo
Se una chiamata opta per la compressione del frame LZ4, lo stesso payload JSON in genere viene fatturato a circa il 25-40% della sua dimensione non compressa per le righe transazionali e al 10-20% per i carichi di lavoro analitici con colonne ripetute, perché questa è la quantità di dati che la rete del tuo partner ha effettivamente spostato. La sandbox nel browser mostra entrambi i numeri (X-QS-Bytes-Wire e X-QS-Byte-grezzi) in modo da poter visualizzare i risparmi prima di condividere un endpoint. Abbiamo scelto di fatturare in base ai byte di rete (quando LZ4 è abilitato) perché questo è il numero che corrisponde sia ai costi di uscita dei dati sia al consumo di larghezza di banda del destinatario. Compressione HTTP standard (gzip) è pura ottimizzazione del trasporto e non influisce sulla fatturazione. Le chiamate che non richiedono LZ4 continuano a essere fatturate in base ai byte non compressi., in linea con le modalità di fatturazione attuali di Excel, Fogli Google e del server MCP.
La decompressione lato client richiede una riga per ogni lingua. Di seguito è riportato il codice di integrazione canonico per ciascun ambiente per cui forniamo esempi:
Progettate per la condivisione di dati tra partner, non per API su scala internet.
La piattaforma API Query Streams è progettata per i casi d'uso in cui si conoscono i destinatari: clienti, fornitori, team interni, autorità di regolamentazione, revisori dei conti, membri del consiglio di amministrazione. Le quote per endpoint, i limiti mensili di byte e i limiti di frequenza per destinatario presuppongono da decine a migliaia di chiamate al giorno per ciascun destinatario. Se il caso d'uso è un'API di marketing pubblica che deve gestire milioni di richieste anonime al secondo, probabilmente è preferibile un gateway API come Kong, Apigee o AWS API Gateway posizionato davanti a un servizio sviluppato internamente. La piattaforma API integra questo modello, non lo sostituisce.
Domande frequenti
Devo aprire le porte del firewall in entrata per esporre il mio database come API? +
Il destinatario può visualizzare le mie credenziali SQL o del mio database? +
Come faccio a revocare l'accesso API di un partner? +
401 CHIAVE_REVOCATAGli altri destinatari dello stesso endpoint continuano a lavorare con le proprie chiavi e non è necessario ruotare la password del database.Qual è la differenza tra le modalità di risposta statica e in streaming? +
Lunghezza del contenutoe genera un corpo HTTP. I limiti predefiniti sono 8 MB / 100.000 righe; il massimo della piattaforma è 50 MB / 1 milione di righe. Ideale per dashboard, query con meno di 10.000 righe e utenti curl. Streaming modalità emette Transfer-Encoding: chunked e invia le righe lungo la rete man mano che l'agente le produce. I limiti predefiniti sono 1 GB / 10 milioni di righe; il massimo della piattaforma è 50 GB / 100 milioni di righe. Ideale per flussi n8n / Zapier, pipeline di analisi ed esportazioni in blocco. La modalità viene scelta per ogni endpoint; il destinatario sceglie il formato di trasmissione (JSON, NDJSON, CSV o frame LZ4) per ogni chiamata.Come posso decomprimere le risposte in formato LZ4 nel mio codice? +
04 22 4D 18), quindi ogni libreria LZ4 principale lo gestisce nativamente. In Python: lz4.frame.decompress(resp.content). In Node.js con lz4js: LZ4.decompressFrame(buffer). In Vai con github.com/pierrec/lz4/v4: lz4.NewReader(body). Sulla riga di comando: curl ... | lz4 -d -. Per gli endpoint di streaming, il corpo della risposta è una sequenza di frame LZ4 concatenati su Transfer-Encoding: chunked — lo stesso decodificatore di frame gestisce in modo identico input a singolo frame e a frame concatenati quando viene chiamato in un ciclo di streaming.È possibile limitare l'accesso di un endpoint a specifici indirizzi IP o browser di origine? +
403 IP_NON_CONSENTITO prima che venga eseguito qualsiasi SQL. Separatamente, ogni endpoint ha un facoltativo Elenco delle origini consentite CORS — impostalo su ["https://app.acme.com"] È possibile specificare se l'endpoint deve essere chiamato dal frontend di uno specifico partner, oppure disattivarlo completamente (impostazione predefinita) per gli endpoint server-to-server. Entrambe le opzioni di controllo si modificano dalla scheda Installa e hanno effetto immediato.Come viene fatturato l'utilizzo della piattaforma API? +
Accept-Encoding: lz4), la fatturazione si basa sui byte compressi del cavo; altrimenti, la fatturazione si basa sui byte non compressi. Lo stesso payload JSON su LZ4 in genere viene fatturato al 25-40% della sua dimensione non compressa per le righe transazionali e al 10-20% per i carichi di lavoro analitici, perché questa è la quantità di dati effettivamente spostata dalla rete del partner. La sandbox nel browser mostra entrambi i numeri uno accanto all'altro. Compressione standard del cavo HTTP (gzip) è pura ottimizzazione del trasporto e non influisce sulla fatturazione.Cosa succede se una query tenta di scrivere o eliminare dati? +
VIOLAZIONE DI SOLA LETTURA prima ancora che raggiunga il tuo database, il validatore di sola lettura dell'agente viene eseguito nella tua rete e consente solo istruzioni SELECT. Perché ogni endpoint è di sola lettura per impostazione predefinita →Quali database SQL sono supportati dalla piattaforma API? +
Posso vedere cosa ha richiesto esattamente ciascun destinatario? +
Come si confronta questa soluzione con la creazione autonoma di un'API utilizzando Express, FastAPI o PostgREST? +
La piattaforma API richiede un abbonamento separato oltre a Query Streams? +
Iniziare
Crea la tua prima API condivisa in cinque minuti.
Registrati gratuitamente, installa l'agente di rete accanto al tuo database, salva una query SQL e invia un invito di richiesta tramite link magico al destinatario. Chiavi per singolo destinatario, tracciabilità delle operazioni e fatturazione ottimizzata per la compressione sono attive fin dal primo minuto.
Guide correlate: Condividi i dati del database in tempo reale senza condividere le credenziali | Condividi i risultati della query in modo sicuro | Guide all'installazione dei connettori | Tutte le guide del server MCP
Categoria: Piattaforma API
Tag: api-platform, rest-api, share-live-data, partner-api, per-recipient-keys, sql-to-api, instant-api, streaming-api, ndjson, lz4-compression, openapi, postgres, mysql, sql-server, snowflake
Meta Description: API REST istantanea per i database SQL più diffusi: statica o in streaming, JSON/NDJSON/CSV/frame LZ4, chiavi per destinatario, OpenAPI 3.1, nessuna credenziale condivisa.
English 
Spanish 
German 
French 
Portuguese 
Japanese 
Korean 
Chinese 
Italian 
Dutch 
Indonesian 
Polish