Wenn Sie Wildberries, Ozon oder eine andere Website durch das Laden vollständiger HTML-Seiten parsen, zahlen Sie 5-10 Mal mehr für den Proxy-Traffic, als Sie müssten. Jede Produktseite hat eine Größe von 200-800 KB an Markup, Skripten und Stilen, von denen Sie buchstäblich nur einige Felder benötigen: Preis, Verfügbarkeit, Bewertung. In diesem Artikel erklären wir, wie man das versteckte API der Website findet und dieselben Daten direkt im kompakten JSON-Format erhält.
Warum das Parsen von HTML den Proxy-Traffic frisst
Wenn der Parser eine Seite über eine normale HTTP-Anfrage oder über einen Headless-Browser (Selenium, Puppeteer, Playwright) lädt, gibt der Server das vollständige HTML-Dokument zurück: Markup, Inline-Skripte, Stile, manchmal base64-Bilder und Hunderte von Zeilen JSON mit Daten für Werbe-Widgets, die Sie nicht benötigen. Eine durchschnittliche Produktkarte auf Wildberries wiegt 300-600 KB, auf Ozon bis zu 800 KB, wenn man alle zugehörigen Ressourcen (CSS, Schriftarten, Tracker) berücksichtigt.
Wenn Sie 10.000 Produkte einmal täglich über 3 Proxy-Sitzungen überwachen, summiert sich das leicht auf Dutzende von Gigabyte Traffic pro Monat. Residente und mobile Proxys werden normalerweise nach Traffic verkauft, daher ist jedes zusätzliche Megabyte direkte Kosten. Die tatsächlichen Daten, die Sie benötigen — Preis, Rabatt, Lagerbestand, Bewertung — nehmen im JSON-Antwortformat 1-5 KB ein. Der Unterschied beträgt 100-200 Mal im Volumen pro Produkt, und unter Berücksichtigung der Overheadkosten für das Rendering im Browser ergibt sich eine noch größere Einsparung bei Zeit und CPU.
Ein zusätzliches Problem beim HTML-Parsen ist die Fragilität. Marktplatz-Websites ändern regelmäßig das Layout, CSS-Klassen, die DOM-Struktur. Jede solche Änderung bricht den Parser, der auf XPath oder CSS-Selektoren basiert. Das interne API ändert sich viel seltener, da es sowohl für die Funktionalität der mobilen Anwendung als auch für das Frontend der Website gleichzeitig verantwortlich ist.
Was ist ein verstecktes API und woher kommt es
Fast jede moderne Website ist eine SPA (Single Page Application) oder eine hybride Anwendung, bei der der Browser zunächst das "Gerüst" der Seite lädt und dann über JavaScript zusätzliche Anfragen an das interne API für echte Daten stellt: Preise, Bestände, Bewertungen, Empfehlungen. Diese Anfragen werden als versteckte oder interne APIs bezeichnet — sie sind nicht öffentlich dokumentiert, aber im Traffic des Browsers vollständig offen.
Technisch handelt es sich dabei in der Regel um REST- oder GraphQL-Endpunkte, die Daten im JSON-Format zurückgeben. Zum Beispiel wird bei Wildberries die Produktkarte über Anfragen wie card.wb.ru und wbx-content-v2.wbstatic.net geladen, während Preise und Bestände über eine separate Anfrage an basket-01.wb.ru und ähnliche Domains abgerufen werden. Bei Ozon gilt eine ähnliche Logik: Das Frontend greift auf das interne Composer-API zu, das Daten aus Mikrodiensten aggregiert.
Es ist wichtig zu verstehen: Die Nutzung eines solchen APIs ist formal kein Hack — Sie wiederholen einfach die gleichen Anfragen, die ein normaler Benutzerbrowser stellt. Aber Websites schützen diese Endpunkte durch Anti-Bot-Systeme, daher ist eine sorgfältige Nachahmung des Verhaltens eines echten Kunden erforderlich, einschließlich qualitativ hochwertiger Proxys.
Wie man versteckte APIs über DevTools findet
Sie können das interne API ohne eine einzige Zeile Code finden, indem Sie die integrierten Tools des Browsers Chrome oder Firefox verwenden. Hier ist ein schrittweiser Algorithmus:
- Öffnen Sie die gewünschte Produktseite in Chrome, drücken Sie F12 und wechseln Sie zur Registerkarte Netzwerk.
- Wählen Sie im Anfragefilter den Typ Fetch/XHR — so filtern Sie das Laden von Bildern, Schriftarten und Statischen Inhalten heraus.
- Aktualisieren Sie die Seite (F5) und sehen Sie sich die Liste der Anfragen an, die nach dem Laden des Seitengerüsts erschienen sind.
- Finden Sie die Anfrage, in deren Antwort (Registerkarte Antwort) der Preis des Produkts, der Name oder andere benötigte Felder im JSON-Format sichtbar sind.
- Klicken Sie auf diese Anfrage und kopieren Sie sie als cURL (rechte Maustaste → Kopieren → Als cURL kopieren) — dies gibt Ihnen den vollständigen Satz von Headern, Cookies und Parametern.
- Überprüfen Sie, welche Parameter in der URL erforderlich sind (Artikelnummer, Region, API-Version) und welche ohne Datenverlust weggelassen werden können.
Danach reicht es aus, diese Anfrage über eine normale HTTP-Bibliothek zu wiederholen, indem Sie die benötigte Artikelnummer oder ID des Produkts anstelle des Renderns der gesamten Seite einfügen. Dies funktioniert für die meisten Marktplätze — Wildberries, Ozon, Avito sowie für viele ausländische Plattformen wie Amazon und eBay.
Vergleich des Traffics: HTML vs JSON API
Der Unterschied im Datenvolumen ist so groß, dass es sich lohnt, ihn in Zahlen zu zeigen. Unten sind die durchschnittlichen Messungen für eine Produktkarte auf beliebten Marktplätzen aufgeführt.
| Parsing-Methode | Durchschnittliche Antwortgröße | Ladezeit | JS-Rendering erforderlich |
|---|---|---|---|
| Vollständiges HTML über Selenium | 400-800 KB | 1.5-4 Sek. | Ja |
| Einfache HTTP-Anfrage (requests) | 150-300 KB | 0.3-0.8 Sek. | Nein |
| Verstecktes JSON API | 3-15 KB | 0.1-0.3 Sek. | Nein |
Bei der Überwachung von 50.000 Produkten pro Tag reduziert der Wechsel von einem Headless-Browser zu direkten Anfragen an das API den Traffic von etwa 30-40 GB auf 300-700 MB pro Monat. Dies ist nicht nur eine Einsparung bei den Proxy-Kosten, sondern auch eine Verringerung der Belastung der Serverinfrastruktur des Parsers — weniger CPU für das Rendering, weniger Speicher, schnellere Datensammlung.
Praktisches Beispiel in Python
Betrachten wir ein vereinfachtes Beispiel: Abrufen des Preises und des Bestands eines Produkts über eine direkte Anfrage an das interne API anstelle des Ladens der vollständigen Seite. Dies ist eine Lernvorlage — die genauen Endpunkte und Parameter müssen über DevTools für die spezifische Website bestimmt werden, da die Struktur der Anfragen je nach Region und API-Version variieren kann.
import requests
def get_product_data(product_id: str, proxies: dict = None) -> dict:
"""
Ruft Produktdaten über das interne API ab, anstelle von vollständigem HTML.
proxies — ein Dictionary mit Proxys im Format requests: {"http": "...", "https": "..."}
"""
url = f"https://card.example-marketplace.ru/v2/detail"
params = {
"nm": product_id,
"dest": "-1257786", # Region, bestimmt über 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)
Beachten Sie drei Punkte in diesem Beispiel. Erstens geben wir den Header Referer an, da viele APIs überprüfen, dass die Anfrage "aus dem Browser" kommt und nicht direkt über die URL. Zweitens verwenden wir einen realistischen User-Agent und nicht den Standard von der requests-Bibliothek, der leicht erkannt werden kann. Drittens wird die gesamte Anfrage in einem HTTP-Aufruf ohne Rendering abgewickelt — das führt zu einem mehrfachen Gewinn bei Traffic und Geschwindigkeit.
Für GraphQL-Endpunkte ist die Logik ähnlich, aber anstelle von GET-Parametern senden Sie eine POST-Anfrage mit einem Anfragekörper im JSON-Format, in dem Sie die benötigten Felder explizit auflisten — das reduziert das Antwortvolumen noch weiter, da der Server nur die angeforderten Daten zurückgibt.
Arbeiten mit Proxys bei API-Anfragen
Selbst beim Wechsel zu einem kompakten JSON-Format benötigen Sie weiterhin Proxys — Marktplätze beschränken die Anzahl der Anfragen von einer IP und sperren bei anomaler Aktivität. Die richtige Wahl des Proxy-Typs hat hier direkten Einfluss auf die Stabilität des Parsers.
Für das massenhafte Umgehen von APIs von Marktplätzen wie Wildberries oder Ozon eignen sich Rechenzentrums-Proxys gut — sie bieten hohe Geschwindigkeit und niedrige Traffic-Kosten, was bei häufigen Anfragen an leichte JSON-Endpunkte entscheidend ist. Wenn jedoch ein bestimmtes API durch ein strengeres Anti-Bot-System geschützt ist und Rechenzentrums-Subnetze vollständig sperrt, ist es sinnvoller, auf residente Proxys umzuschalten — sie verwenden echte IP-Adressen von Haushaltsnutzern und werden seltener aufgrund von Subnetzblockierungen gesperrt.
Für APIs, die an mobile Anwendungen gebunden sind (einige Versionen von Endpunkten von Avito oder Marktplätzen geben Daten nur über mobilen Traffic aus), kann eine Verbindung über mobile Proxys erforderlich sein — sie simulieren den Traffic echter Mobilfunkanbieter und bestehen Prüfungen, die normale IPs blockieren.
Bei der Konfiguration von Proxys im Parser ist es auch wichtig, die Anfragen zeitlich zu verteilen und IP-Rotation zu verwenden — selbst eine kompakte JSON-Anfrage, die 1000 Mal pro Minute von einer Adresse wiederholt wird, wird das System zur Sicherheitsüberprüfung misstrauisch machen. Richten Sie einen Pool aus mehreren Proxy-Sitzungen ein und verteilen Sie die Last zwischen ihnen, indem Sie zufällige Verzögerungen von 1-3 Sekunden zwischen den Anfragen hinzufügen.
Fallstricke: Tokens, Signaturen, Anti-Bot
Versteckte APIs sind nicht immer offen. Einige Websites schützen ihre Endpunkte mit zusätzlichen Mechanismen, die bei der Erstellung des Parsers berücksichtigt werden müssen.
- Temporäre Sitzungstokens — einige APIs erfordern eine vorherige Anfrage nach einem Token, das dann in den Headern der folgenden Anfragen übergeben wird und eine begrenzte Zeit (normalerweise 5-30 Minuten) gültig ist.
- Signatur der Anfrage (signature) — die Parameter der Anfrage werden auf dem Client mit einem geheimen Schlüssel aus dem JS-Code der Seite gehasht. Diese Signatur muss entweder manuell reproduziert werden, indem der Algorithmus analysiert wird, oder über einen Headless-Browser nur in der Phase des Token-Abrufs ausgeführt werden, während danach leichte Anfragen direkt gesendet werden.
- Rate Limiting nach IP und User-Agent — bei Überschreitung der Anfragefrequenz sperrt die Website vorübergehend den Zugriff. Dies kann durch Proxy-Rotation und angemessene Verzögerungen gelöst werden.
- Fingerprinting der Header — einige Systeme überprüfen die vollständige Headerliste (Reihenfolge, Vorhandensein von Accept-Language, Sec-Fetch-*) und blockieren Anfragen mit einem "unvollständigen" Satz, der für Skripte und nicht für Browser charakteristisch ist.
- Geo-Abhängigkeit der Daten — Preise und Bestände auf Marktplätzen können je nach Region variieren, daher ist es wichtig, den korrekten Parameter für Region/Lager im Anfrage zu übergeben, sonst sind die Daten nicht relevant.
Wenn das API durch eine Anfrage-Signatur geschützt ist, die schwer zu reproduzieren ist, ist eine Kompromisslösung, einen Headless-Browser (Playwright, Puppeteer) nur zum Abfangen von Netzwerk-Anfragen und zum Extrahieren der fertigen JSON-Antwort zu verwenden, ohne das DOM zu parsen. Dies ist langsamer als eine direkte HTTP-Anfrage, aber immer noch schneller und einfacher als ein vollständiges Parsing des Seitenlayouts.
Checkliste vor dem Start des Parsers auf verstecktem API
- Der Endpunkt wurde über DevTools gefunden, als cURL kopiert und in Postman oder über requests getestet.
- Die erforderlichen Anfrageparameter (Produkt-ID, Region, API-Version) wurden bestimmt und überflüssige ausgeschlossen.
- Die Header User-Agent, Referer und Accept-Language wurden realistisch konfiguriert.
- Überprüft, ob ein Sitzungstoken oder eine Anfrage-Signatur erforderlich ist, und einen Weg zu deren Beschaffung durchdacht.
- Proxy-Rotation und zufällige Verzögerungen zwischen den Anfragen wurden eingerichtet.
- Der geeignete Proxy-Typ für den spezifischen Schutz der Website wurde ausgewählt — Rechenzentrum, residente oder mobile.
- Die Behandlung von Fehlern 429 und 403 mit automatischem Wechsel zu einem anderen Proxy wurde hinzugefügt.
- Das Logging des Traffic-Volumens zur Kontrolle der tatsächlichen Einsparungen wurde eingerichtet.
Fazit
Der Wechsel vom Parsen vollständiger HTML-Seiten zur Arbeit mit versteckten APIs ist nicht nur eine technische Optimierung, sondern führt direkt zu einer Senkung der Ausgaben für Proxy-Traffic und Infrastruktur. Anstelle des Ladens von Hunderten von Kilobyte überflüssigem Markup erhalten Sie kompaktes JSON mit genau den Feldern, die für die Überwachung von Preisen, Beständen oder Bewertungen erforderlich sind. Ein zusätzlicher Vorteil ist die Robustheit des Parsers gegenüber Änderungen im Seitenlayout, da sich interne APIs seltener ändern als das Frontend.
Gleichzeitig hebt die Methode zur Suche nach APIs nicht die Notwendigkeit für qualitativ hochwertige Proxys auf — die Anti-Bot-Systeme der Marktplätze überwachen sowohl HTML-Anfragen als auch Anfragen an JSON-Endpunkte gleichermaßen genau. Wenn Sie Wildberries oder Ozon in großem Umfang überwachen, beginnen Sie mit schnellen Rechenzentrums-Proxys, um die Kosten zu senken, und wechseln Sie bei den ersten Anzeichen von Blockierungen zu residenten oder mobilen IP-Pools für eine stabilere Funktion des Parsers.