GET oder POST für Screenshot-API-Läufe
Nutze GET für schnelle URL-Ausführungen und POST für Screenshot-API-Anfragen mit Headern, Cookies, Schritten, Labels oder Speicherzielen.
Auf dieser Seite
Nützlich wenn
- Nutze GET für schnelle URL-Ausgaben als Screenshot, PDF, HTML oder Markdown.
- Nutze POST für Cookies, Header, Schritte, Dateiausgabe, Speicherziele oder längere Daten.
- Wenn sensible Werte doch durch eine URL laufen müssen, verwende einen engen und kurzlebigen API-Schlüssel.
Wann GET reicht und wann POST besser ist
Eine Screenshot-API beginnt oft mit einer einfachen URL. Dafür bleibt GET nützlich: Zielseite, Ausgabeformat, Viewport und Cache senden, dann das Ergebnis abrufen.
POST passt, sobald der Lauf Teil eines Arbeitsablaufs wird. Header, Cookies, HTML-Eingabe, Markdown-Ausgabe, Labels, Speicherziele und Schritte bleiben im Request Body lesbarer. Sensible Werte landen nicht in Browserhistorie, Serverlogs oder geteilten URLs.
Warum das in echten Abläufen zählt
GET ist gut für ein schnelles Render-Ergebnis. POST passt, wenn dieselbe Seite erneut geprüft, gelabelt, gespeichert oder mit einer Veröffentlichung verbunden werden soll.
RenderLog hält beide Varianten in derselben Historie. Entwickler können mit einem API-Aufruf starten, und das Team kann dasselbe Ziel später in manuelle Prüfung, Prüfsuiten, Referenzen und Benachrichtigungen übernehmen.
- CI-Jobs können einfache Render-Aufrufe kurz halten.
- Backend-Dienste können strukturierte Requests senden, ohne jede Option in die URL zu packen.
- Das Team bekommt nach dem API-Aufruf weiterhin Ergebnisdateien, Logs, Labels und Prüfhistorie.