Scegliete il feed che fornisce i campi necessari con un aggiornamento tracciabile e una ripresa sicura, non quello il cui nome sembra più moderno. Un CSV completo depositato ogni giorno può essere preferibile a un'API senza timestamp né paginazione affidabile. Un'API diventa interessante per variazioni frequenti e richieste mirate; XML è adatto a strutture annidate e documentate; FTP è un canale di trasferimento, spesso usato per depositare file, non un formato di catalogo. Prima di decidere, testate la documentazione, il volume, i limiti, gli identificativi, il prezzo, lo stock, la sicurezza e il comportamento in caso di interruzione.
Separare formato, trasporto e contratto di accesso
CSV e XML descrivono principalmente una rappresentazione di dati. HTTP e FTP descrivono meccanismi di scambio. Una "API JSON" combina generalmente un contratto applicativo, documenti JSON e un trasporto HTTP. Un "feed FTP" può contenere un CSV, un XML, un archivio o più file. Mescolare questi livelli porta a confronti falsati.
L'RFC 4180 documenta un formato CSV comunemente usato e il suo tipo MIME. Descrive in particolare le righe, i separatori e l'escape dei campi tra virgolette, ma non definisce le colonne price, stock o ean. La raccomandazione XML del W3C definisce la sintassi e la corretta formazione dei documenti XML; non fornisce nemmeno lo schema di business del fornitore. In entrambi i casi, la documentazione del produttore resta indispensabile.
FTP, standardizzato storicamente dall'RFC 959 e integrato da aggiornamenti successivi, serve al trasferimento di file tra host. La sua esistenza non significa che la connessione sia cifrata né che il contenuto sia recente. Bisogna verificare il protocollo realmente offerto, il metodo di autenticazione, le protezioni di trasporto e la politica di rotazione degli accessi senza esporre segreti nei log.
Una matrice di scelta basata sui fatti
| Opzione | Punto di forza tipico | Rischio da controllare | Buon caso d'uso |
|---|---|---|---|
| CSV | Semplice da archiviare, confrontare e riprodurre | Codifica, separatore, colonne piatte, file completi voluminosi | Esportazione periodica stabile |
| XML | Struttura gerarchica e schema possibile | Namespace, documenti mal formati, complessità di annidamento | Prodotti, varianti e offerte strutturati |
| API HTTP | Richieste mirate, paginazione, aggiornamenti frequenti | Quote, autenticazione, paginazione, versioni, errori parziali | Stock o prezzi consultati regolarmente |
| Deposito FTP | Consegna automatizzata di file | Sicurezza del canale, file incompleti, convenzione di denominazione | Grandi esportazioni pianificate |
Questa matrice non classifica una tecnologia in assoluto. Serve a far emergere le domande che il fornitore deve documentare. Un feed va giudicato sulle sue prove reali: esempio di risposta, dizionario dei dati, cadenza dichiarata, condizioni d'uso, metodo di ripresa e contatto in caso di incidente.
I criteri che decidono davvero
Completezza di business
Elencate i campi non negoziabili prima di discutere di tecnologia: identificativo di prodotto e variante, SKU, brand, titolo, prezzo, valuta, natura IVA esclusa/inclusa, stock con il suo livello di precisione, unità di vendita, MOQ, step d'ordine, immagine e timestamp. Usate la griglia delle colonne di un catalogo grossista per evitare che una dimostrazione tecnica nasconda l'assenza di un dato essenziale.
Freschezza e prova di cambiamento
Chiedete se il feed è completo o incrementale. Per un file completo, cercate una data di generazione e un meccanismo che impedisca la lettura prima del completamento del deposito. Per un'API, documentate la paginazione, l'ordinamento stabile, i cursori e la semantica delle cancellazioni. I campi HTTP ETag e Last-Modified sono validatori definiti dall'RFC 9110, ma la loro presenza e il loro significato dipendono dal server. Non sostituiscono un timestamp di business del prezzo o dello stock.
Il tempo di fiducia di prezzi e stock va scelto in base al rischio commerciale. Un catalogo di caratteristiche può evolvere lentamente; una disponibilità può cambiare tra due ordini. Lo stesso ciclo non va bene necessariamente per entrambe le famiglie di campi.
Ripresa e idempotenza
Simulate un'interruzione. Potete riprendere dalla pagina successiva senza perdere né duplicare prodotti? Un file ha un nome temporaneo prima di essere dichiarato completo? Un'API fornisce un identificativo e un ordine stabili? Gli aggiornamenti devono essere idempotenti: rigiocare lo stesso documento non deve moltiplicare le offerte.
Archiviate l'impronta del contenuto accettato, la data di raccolta, l'URL o il nome del file e la versione del parser. Questa tracciabilità permette di capire se una differenza proviene dal fornitore o dalla vostra trasformazione.
Sicurezza e diritti
Non inserite mai una chiave API nel codice, nel CSV prodotto o in un messaggio di errore. Limitate gli accessi al perimetro necessario e seguite la procedura di rotazione del fornitore. Verificate anche la licenza o le condizioni d'uso: una risorsa tecnicamente accessibile non è automaticamente autorizzata al riutilizzo commerciale. L'RFC 9309 ricorda peraltro che robots.txt non è una forma di autorizzazione d'accesso.
Test di selezione in nove passaggi
1. Ottenere la documentazione ufficiale e le condizioni d'uso. 2. Elencare i campi obbligatori e la loro definizione. 3. Verificare un piccolo campione che comprenda varianti, rotture di stock e valori vuoti. 4. Misurare il volume e capire la paginazione o la suddivisione dei file. 5. Identificare frequenza, timestamp e segnali di cambiamento. 6. Provocare un errore controllato e osservare il codice, il messaggio e la ripresa. 7. Rigiocare lo stesso estratto per verificare l'assenza di duplicati. 8. Confrontare i dati con schede ufficiali autorizzate. 9. Lanciare un lotto canarino fornitore prima di aumentare il volume.
Alla fine, redigete una scheda di decisione con tre colonne: "dimostrato", "non fornito" e "da confermare". Il termine "supportato" va usato solo se un test o una documentazione ufficiale lo dimostra.
Checklist di collegamento
- Formato e trasporto sono identificati separatamente.
- Lo schema di business e le unità sono documentati.
- Paginazione, quote e volume sono stati testati.
- Il timestamp di generazione è disponibile o segnato come assente.
- Una ripresa dopo interruzione è stata verificata.
- Le cancellazioni e le rotture di stock hanno una semantica chiara.
- I segreti restano fuori da file e log.
- Le condizioni autorizzano l'uso previsto.
- Le risposte grezze e le loro impronte sono archiviate.
- Il canarino passa prima dell'importazione completa.
Cosa può automatizzare ArbitragePro+ / cosa deve verificare il venditore
La specifica proposta diagnostic-flux potrebbe controllare struttura, tipi, paginazione, stabilità degli identificativi, impronte ed errori di un canarino. Potrebbe confrontare i campi forniti con i requisiti dichiarati, senza pretendere di definire il contratto del fornitore.
Il venditore deve scegliere la fonte autorizzata, ottenere gli accessi, confermare la base fiscale e le unità, valutare la sicurezza del canale, poi validare che la frequenza sia adatta al proprio modello d'ordine.
Identificare il collegamento adatto
Consultare le fonti monitorate da ArbitragePro+ per esaminare le informazioni disponibili su ogni connessione.
Fonti ufficiali
- IETF, RFC 4180, «Common Format and MIME Type for CSV Files», https://www.rfc-editor.org/info/rfc4180/ — consultato il 2026-08-17.
- W3C, «Extensible Markup Language (XML) 1.0», https://www.w3.org/TR/xml/ — consultato il 2026-08-17.
- IETF, RFC 9110, «HTTP Semantics», https://www.rfc-editor.org/rfc/rfc9110.html — consultato il 2026-08-17.
- IETF, RFC 959, «File Transfer Protocol», https://www.rfc-editor.org/info/rfc959/ — consultato il 2026-08-17.
- IETF, RFC 9309, «Robots Exclusion Protocol», https://www.rfc-editor.org/rfc/rfc9309.html — consultato il 2026-08-17.
