Web Scraping

Kurz: Das automatisierte Auslesen von Daten aus Webseiten per Skript — entweder aus rohem HTML oder über eine offizielle API, falls vorhanden.

Genauer: Für einfache Seiten ohne eigene API reichen HTTP-Requests + ein HTML-Parser (Python: requests + BeautifulSoup; Node.js: fetch/axios + cheerio). Braucht die Seite JavaScript zum Rendern (viele moderne Admin-Oberflächen), reicht das nicht mehr — dann braucht es einen echten (headless) Browser wie Playwright oder Puppeteer. Login-geschützte Seiten: Session-Cookie/Token einmal per Login-Formular holen, dann wiederverwenden. Existiert eine offizielle API, ist die fast immer die bessere Wahl (stabiler, nicht ToS-riskant) — Scraping ist meist nur der Fallback.

Kontext bei uns: Kam als kurzer Exkurs auf — allgemeine Frage, wie man eigene Geräte/Dienste im Heimnetz (Router, NAS, Smart-Home) oder eigene Accounts auf Plattformen automatisiert abfragen könnte, unabhängig vom Emzett-Projekt.

Im Detail

Zwei technische Hürden entscheiden meist, wie aufwendig ein Scraping-Projekt wird. Erstens: statisches vs. dynamisches HTML. Liefert der Server das komplette HTML mit allen Inhalten direkt aus (View Source zeigt den Text, den man auch im Browser sieht), reicht ein einfacher HTTP-Request. Baut die Seite ihren Inhalt erst per JavaScript im Browser zusammen (View Source zeigt nur ein leeres Grundgerüst), muss der Scraper einen echten Browser tatsächlich ausführen lassen, um an den fertigen Inhalt zu kommen — deutlich langsamer und ressourcenintensiver.

Zweitens: Anti-Scraping-Maßnahmen. Viele Seiten erkennen automatisierte Zugriffe an Mustern wie fehlenden/untypischen Browser-Headern, zu regelmäßigen Anfrageintervallen, oder fehlendem Mausverhalten, und blockieren sie dann (oft mit CAPTCHAs oder stillem Ausliefern falscher Daten). Rechtlich bewegt sich Scraping in einer Grauzone: öffentlich zugängliche Daten zu lesen ist meist erlaubt, aber Nutzungsbedingungen (ToS) können es explizit untersagen, und aggressives Scraping (viele Anfragen in kurzer Zeit) kann als Angriff auf die Serverkapazität gewertet werden — ein weiterer Grund, eine offizielle API zu bevorzugen, wenn eine existiert.

import requests
from bs4 import BeautifulSoup
 
response = requests.get(url, headers={"User-Agent": "..."})
soup = BeautifulSoup(response.text, "html.parser")

robots.txt und Etikette

Die meisten Webseiten veröffentlichen unter /robots.txt maschinenlesbare Regeln, welche Bereiche automatisierte Programme (Crawler/Scraper) besuchen dürfen und welche nicht — rechtlich nicht direkt bindend, aber ein klares Signal des Seitenbetreibers, das seriöse Scraper respektieren sollten. Zusätzlich gehört zu fairem Scraping: Anfragen künstlich verzögern (nicht dutzende parallele Requests gleichzeitig feuern), einen ehrlichen User-Agent-Header setzen statt sich als normaler Browser auszugeben, und bei wiederholtem Bedarf lieber zwischenspeichern statt dieselbe Seite wiederholt neu abzurufen.

Wann sich ein echter Browser lohnt

Playwright/Puppeteer steuern einen echten (meist unsichtbaren “headless”) Browser fern — das macht sie deutlich langsamer und ressourcenhungriger als ein reiner HTTP-Request, dafür können sie mit JavaScript-lastigen Seiten, Logins über echte Formulare, und Interaktionen wie Scrollen oder Klicken umgehen, die ein reiner HTML-Parser gar nicht abbilden kann:

from playwright.sync_api import sync_playwright
 
with sync_playwright() as p:
    browser = p.chromium.launch()
    page = browser.new_page()
    page.goto(url)
    page.wait_for_selector(".content")  # warten bis JS die Inhalte gerendert hat
    html = page.content()

Siehe auch: HTML, API, Browser