Se stai estraendo dati da Wildberries, Ozon o qualsiasi altro sito caricando pagine HTML complete, stai pagando per il traffico del proxy da 5 a 10 volte di più di quanto potresti. Ogni pagina del prodotto è composta da 200-800 KB di markup, script e stili, di cui hai bisogno solo di pochi campi: prezzo, disponibilità, valutazione. In questo articolo analizziamo come trovare l'API nascosta del sito e ottenere gli stessi dati direttamente in un formato JSON compatto.
Perché il parsing HTML consuma traffico del proxy
Quando il parser carica una pagina tramite una normale richiesta HTTP o tramite un browser headless (Selenium, Puppeteer, Playwright), il server restituisce un documento HTML completo: markup, script inline, stili, a volte immagini in base64 e centinaia di righe di JSON con dati per widget pubblicitari che non ti servono. La scheda media di un prodotto su Wildberries pesa 300-600 KB, su Ozon fino a 800 KB, considerando tutte le risorse correlate (CSS, font, tracker).
Se monitori 10.000 prodotti una volta al giorno tramite 3 sessioni proxy, questo facilmente si traduce in decine di gigabyte di traffico al mese. I proxy residenziali e mobili vengono solitamente venduti in base al traffico, quindi ogni megabyte extra è una spesa diretta. Tuttavia, i dati reali di cui hai bisogno - prezzo, sconto, giacenza, valutazione - occupano nella risposta JSON solo 1-5 KB. La differenza è di 100-200 volte in volume per un singolo prodotto, e considerando le spese generali per il rendering del browser, il risparmio in termini di tempo e CPU è ancora maggiore.
Un ulteriore problema del parsing HTML è la fragilità. I siti dei marketplace cambiano regolarmente il layout, le classi CSS, la struttura del DOM. Ogni cambiamento di questo tipo rompe il parser costruito su XPath o selettori CSS. L'API interna cambia molto meno frequentemente, poiché da essa dipende il funzionamento dell'app mobile e del frontend del sito contemporaneamente.
Che cos'è un API nascosta e da dove proviene
Quasi ogni sito moderno è un SPA (Single Page Application) o un'applicazione ibrida, dove il browser prima carica lo "scheletro" della pagina e poi tramite JavaScript fa richieste aggiuntive all'API interna per i dati reali: prezzi, giacenze, recensioni, raccomandazioni. Queste richieste sono chiamate API nascoste o interne - non sono documentate pubblicamente, ma sono completamente aperte nel traffico del browser.
Tecnicamente, si tratta di solito di endpoint REST o GraphQL che restituiscono dati in formato JSON. Ad esempio, su Wildberries la scheda del prodotto viene caricata tramite richieste di tipo card.wb.ru e wbx-content-v2.wbstatic.net, mentre i prezzi e le giacenze vengono richiesti separatamente su basket-01.wb.ru e domini simili. Su Ozon la logica è simile: il frontend accede all'API interna composer, che aggrega i dati dai microservizi.
È importante capire: l'uso di tale API non è formalmente un hacking - stai semplicemente ripetendo le stesse richieste che fa un normale browser utente. Ma i siti proteggono questi endpoint tramite sistemi anti-bot, quindi è necessaria una simulazione accurata del comportamento di un cliente reale, anche attraverso proxy di qualità.
Come trovare un API nascosta tramite DevTools
Trovare un API interna è possibile senza scrivere una sola riga di codice, utilizzando gli strumenti integrati del browser Chrome o Firefox. Ecco un algoritmo passo-passo:
- Apri la pagina del prodotto desiderato in Chrome, premi F12 e vai alla scheda Network.
- Nel filtro delle richieste, seleziona il tipo Fetch/XHR - in questo modo escluderai il caricamento di immagini, font e statici.
- Ricarica la pagina (F5) e guarda l'elenco delle richieste che sono apparse dopo il caricamento dello scheletro della pagina.
- Trova la richiesta, nella cui risposta (scheda Response) è visibile il prezzo del prodotto, il nome o altri campi necessari in formato JSON.
- Clicca su questa richiesta e copiala come cURL (tasto destro → Copia → Copia come cURL) - questo ti darà un insieme completo di intestazioni, cookie e parametri.
- Controlla quali parametri nell'URL sono obbligatori (articolo del prodotto, regione, versione API) e quali possono essere rimossi senza perdere dati.
Dopo di che, basta ripetere questa richiesta tramite una normale libreria HTTP, sostituendo l'articolo o l'ID del prodotto invece di dover renderizzare l'intera pagina. Questo funziona per la maggior parte dei marketplace - Wildberries, Ozon, Avito, così come per molte piattaforme estere come Amazon ed eBay.
Confronto del traffico: HTML vs JSON API
La differenza nel volume dei dati è così grande che vale la pena mostrarla in cifre. Di seguito sono riportate le misurazioni medie per una scheda prodotto sui marketplace popolari.
| Metodo di parsing | Dimensione media della risposta | Tempo di caricamento | Richiesta di rendering JS necessaria |
|---|---|---|---|
| HTML completo tramite Selenium | 400-800 KB | 1.5-4 sec | Sì |
| Richiesta HTTP semplice (requests) | 150-300 KB | 0.3-0.8 sec | No |
| API JSON nascosta | 3-15 KB | 0.1-0.3 sec | No |
Monitorando 50.000 prodotti al giorno, il passaggio da un browser headless a richieste dirette all'API riduce il traffico da circa 30-40 GB a 300-700 MB al mese. Questo non è solo un risparmio sul traffico dei proxy, ma anche una riduzione del carico sull'infrastruttura server del parser - meno CPU per il rendering, meno memoria, più veloce raccolta dei dati.
Esempio pratico in Python
Consideriamo un esempio semplificato: ottenere il prezzo e la giacenza di un prodotto tramite una richiesta diretta all'API interna invece di caricare l'intera pagina. Questo è un modello didattico - gli endpoint e i parametri esatti devono essere determinati tramite DevTools per un sito specifico, poiché la struttura delle richieste può variare a seconda della regione e della versione dell'API.
import requests
def get_product_data(product_id: str, proxies: dict = None) -> dict:
"""
Ottiene i dati del prodotto tramite l'API interna invece di HTML completo.
proxies - dizionario con proxy nel formato requests: {"http": "...", "https": "..."}
"""
url = f"https://card.example-marketplace.ru/v2/detail"
params = {
"nm": product_id,
"dest": "-1257786", # regione, determinata tramite DevTools
"spp": "0"
}
headers = {
"User-Agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) "
"AppleWebKit/537.36 (KHTML, like Gecko) "
"Chrome/120.0 Safari/537.36",
"Accept": "application/json",
"Referer": f"https://www.example-marketplace.ru/catalog/{product_id}/detail.aspx"
}
response = requests.get(
url,
params=params,
headers=headers,
proxies=proxies,
timeout=10
)
response.raise_for_status()
data = response.json()
product = data["products"][0]
return {
"id": product["id"],
"name": product["name"],
"price": product["salePriceU"] / 100,
"stock": product.get("totalQuantity", 0),
"rating": product.get("reviewRating", None)
}
if __name__ == "__main__":
proxy = {
"http": "http://user:pass@proxy-host:port",
"https": "http://user:pass@proxy-host:port"
}
result = get_product_data("123456789", proxies=proxy)
print(result)
Fai attenzione a tre punti in questo esempio. In primo luogo, specifichiamo l'intestazione Referer, perché molte API controllano che la richiesta provenga "dal browser" e non direttamente dall'URL. In secondo luogo, utilizziamo un User-Agent realistico, e non quello predefinito della libreria requests, che è facilmente rilevabile. In terzo luogo, l'intera richiesta si svolge in una sola chiamata HTTP senza rendering - questo porta a un guadagno significativo in termini di traffico e velocità.
Per gli endpoint GraphQL, la logica è simile, ma invece di parametri GET si invia una richiesta POST con il corpo della richiesta in formato JSON, dove elenchi esplicitamente i campi necessari - questo riduce ulteriormente il volume della risposta, poiché il server restituisce solo i dati richiesti.
Lavorare con i proxy nelle richieste API
Anche passando a un formato JSON compatto, hai comunque bisogno di proxy - i marketplace limitano il numero di richieste da un singolo IP e bloccano in caso di attività anomala. La scelta corretta del tipo di proxy influisce direttamente sulla stabilità del parser.
Per il bypass massiccio delle API dei marketplace come Wildberries o Ozon, i proxy dei data center sono molto adatti - offrono alta velocità e basso costo del traffico, il che è critico per richieste frequenti a endpoint JSON leggeri. Ma se un API specifica è protetta da un anti-bot più severo e blocca interi sottoreti di data center, è più ragionevole passare a proxy residenziali - utilizzano indirizzi IP reali di utenti domestici e vengono bloccati meno frequentemente per sottorete.
Per le API legate ad app mobili (alcune versioni degli endpoint di Avito o marketplace restituiscono dati solo tramite traffico mobile), potrebbe essere necessario connettersi tramite proxy mobili - simulano il traffico di veri operatori di telefonia mobile e superano i controlli che bloccano gli IP normali.
Quando configuri i proxy nel parser, è importante anche distribuire le richieste nel tempo e utilizzare la rotazione degli IP - anche una richiesta JSON compatta ripetuta 1000 volte al minuto da un singolo indirizzo solleverà sospetti nel sistema di protezione. Configura un pool di più sessioni proxy e distribuisci il carico tra di esse, aggiungendo ritardi casuali di 1-3 secondi tra le richieste.
Insidie: token, firme, anti-bot
Le API nascoste non sono sempre completamente aperte. Alcuni siti proteggono i loro endpoint con meccanismi aggiuntivi che devono essere considerati nella costruzione del parser.
- Token di sessione temporanei - alcune API richiedono una richiesta preliminare per ottenere un token, che viene poi passato nell'intestazione delle richieste successive e ha una durata limitata (di solito 5-30 minuti).
- Firma della richiesta (signature) - i parametri della richiesta vengono hashati sul client con una chiave segreta dal codice JS della pagina. Questa firma deve essere riprodotta manualmente, analizzando l'algoritmo, oppure eseguita tramite un browser headless solo nella fase di ottenimento del token, e poi inviare richieste leggere direttamente.
- Rate limiting per IP e User-Agent - superando la frequenza delle richieste, il sito blocca temporaneamente l'accesso. Si risolve con la rotazione dei proxy e ritardi ragionevoli.
- Fingerprinting delle intestazioni - alcuni sistemi controllano l'intero insieme di intestazioni (ordine, presenza di Accept-Language, Sec-Fetch-*) e bloccano le richieste con un insieme "incompleto", tipico degli script e non dei browser.
- Dipendenza geografica dei dati - i prezzi e le giacenze sui marketplace possono variare a seconda delle regioni, quindi è importante passare il parametro corretto della regione/magazzino nella richiesta, altrimenti i dati saranno irrilevanti.
Se l'API è chiusa da una firma di richiesta difficile da riprodurre, un'opzione compromissoria è utilizzare un browser headless (Playwright, Puppeteer) solo per intercettare le richieste di rete e estrarre la risposta JSON pronta, senza fare parsing del DOM. Questo è più lento di una richiesta HTTP diretta, ma è comunque più veloce e più leggero rispetto a un parsing completo del layout della pagina.
Checklist prima di avviare il parser su un API nascosta
- Endpoint trovato tramite DevTools, copiato come cURL e testato in Postman o tramite requests.
- Determinati i parametri obbligatori della richiesta (ID prodotto, regione, versione API) ed esclusi quelli superflui.
- Intestazioni User-Agent, Referer e Accept-Language configurate in modo realistico.
- Verificato se è necessario un token di sessione o una firma della richiesta, e pensato a come ottenerli.
- Configurata la rotazione dei proxy e ritardi casuali tra le richieste.
- Scelto il tipo di proxy appropriato per la protezione specifica del sito - data center, residenziali o mobili.
- Aggiunta la gestione degli errori 429 e 403 con commutazione automatica su un altro proxy.
- Configurato il logging del volume di traffico per controllare il reale risparmio.
Conclusione
Passare dal parsing di HTML completo al lavoro con API nascoste non è solo un'ottimizzazione tecnica, ma una riduzione diretta delle spese per il traffico proxy e l'infrastruttura. Invece di caricare centinaia di kilobyte di markup superfluo, ottieni un JSON compatto con esattamente i campi necessari per monitorare prezzi, giacenze o valutazioni. Ulteriore vantaggio - la resilienza del parser ai cambiamenti nel layout del sito, poiché le API interne cambiano meno frequentemente rispetto al frontend.
Tuttavia, la stessa metodologia di ricerca dell'API non annulla la necessità di proxy di qualità - i sistemi anti-bot dei marketplace monitorano con la stessa attenzione sia le richieste HTML che quelle agli endpoint JSON. Se monitori Wildberries o Ozon in grandi volumi, inizia con veloci proxy dei data center per ridurre i costi, e ai primi segni di blocchi, passa a pool di IP residenziali o mobili per un funzionamento più stabile del parser.