API-Endpunkt-Prüfer

Die Anfrage geht direkt von Ihrem Browser an den Endpunkt, nicht über unseren Server. CORS gilt, Cookies werden nicht gesendet. Im Schrittmodus bleiben die Eingaben vorübergehend in diesem Tab, bis Schritt 2 geladen ist, und werden dann aus dem Sitzungsspeicher gelöscht. Der Endpunkt erhält weiterhin URL, Header, Inhalt und Ihre IP-Adresse.

Fügen Sie eine HTTP- oder HTTPS-URL ein. Das Tool sendet GET, HEAD, POST, PUT, PATCH oder DELETE direkt aus Ihrem Browser. Es zeigt den endgültigen Status, die Zeit bis zu den Antwortheadern, per CORS freigegebene Header, die endgültige URL nach einer Weiterleitung und bis zu 1 MiB des Inhalts. Der Endpunkt muss den Browserursprung per CORS zulassen, damit die Antwort lesbar ist.

So überprüfst du einen API-Endpunkt

  1. 1

    Gib die URL ein

    Schließe das Schema ein (http:// oder https://). Das Tool folgt standardmäßig Weiterleitungen.

  2. 2

    Wähle die HTTP-Methode

    GET ist die Standardmethode. Wechsle zu HEAD für einen leichteren Check, POST/PUT/PATCH mit einem Body für Tests an Schreib-Endpunkten.

  3. 3

    Füge bei Bedarf Header hinzu

    Authorization, Accept, Content-Type und benutzerdefinierte Header können gesetzt werden. Nützlich für das Testen der API-Schlüssel-Authentifizierung oder der Inhaltsverhandlung.

  4. 4

    Prüfe das im Browser sichtbare Ergebnis

    Prüfen Sie Endstatus, Zeit, per CORS freigegebene Header, die endgültige URL nach einer Weiterleitung und eine auf 1 MiB begrenzte Inhaltsvorschau.

HTTP-Statuscode-Referenz

Code Bedeutung Aktion
200 OK Erfolg
201 Erstellt POST/PUT hat eine Ressource erzeugt
204 Kein Inhalt Erfolg ohne Body
301 Dauerhaft verschoben Weiterleitung folgen, Links aktualisieren
302 Gefunden (temporäre Weiterleitung) Weiterleitung folgen
304 Nicht geändert Zwischengespeicherte Kopie ist weiterhin gültig
400 Ungültige Anfrage Anfrage beheben
401 Nicht autorisiert Fehlende oder ungültige Anmeldeinformationen
403 Verboten Authentifiziert, aber nicht erlaubt
404 Nicht gefunden Falsche URL oder Ressource nicht mehr vorhanden
429 Zu viele Anfragen Zurückhalten, Rate-Limit respektieren
500 Interner Serverfehler Serverfehler
502 Ungültiges Gateway Upstream ist nicht erreichbar
503 Dienst nicht verfügbar Wartung oder Überlastung
504 Gateway-Zeitüberschreitung Upstream hat nicht rechtzeitig geantwortet

Antwortzeit-Benchmarks

Antwortzeit Wahrnehmung
Unter 100 ms Sofort
100-300 ms Schnell
300-1000 ms Akzeptabel
1-3 Sekunden Langsam, Nutzer bemerken
Über 3 Sekunden Bei interaktiver Nutzung untersuchen

Dies sind grobe Diagnosebereiche, keine allgemeingültigen Grenzwerte. Wenn die API ein SLA hat, vergleichen Sie mehrere Messungen mit den dort genannten p95- und p99-Zielen.

Häufige Header, die es wert sind, überprüft zu werden

  • Content-Type, application/json; charset=utf-8 vs. text/html sagt dir, was du tatsächlich erhältst.
  • Cache-Control, max-age=3600, public vs. no-store bestimmt, ob CDN- und Browser-Caches verwendet werden.
  • Access-Control-Allow-Origin, für CORS-Debugging. Muss * oder explizit die anfordernde Herkunft sein.
  • Strict-Transport-Security, HSTS-Präsenz bestätigt die Durchsetzung von HTTPS nur.
  • X-RateLimit-Remaining, viele APIs veröffentlichen die verbleibende Quote pro Antwort.

Was eine Browseranfrage nicht zeigen kann

  • Fetch folgt erlaubten Weiterleitungen und zeigt die endgültige URL, aber nicht die vollständige Weiterleitungskette.
  • Der Browser prüft HTTPS, stellt JavaScript aber weder Aussteller noch Ablaufdatum oder Zertifikatskette bereit.
  • CORS entscheidet, ob diese Seite Status, Inhalt und die meisten Header lesen darf. Ein CORS-Fehler beweist nicht, dass die API ausgefallen ist.
  • Header wie Host, Origin, Cookie, Content-Length und User-Agent kontrolliert der Browser; das Tool weist sie zurück, statt ihren Versand vorzutäuschen.

Häufig gestellte Fragen

Fetch folgt Weiterleitungen und stellt die endgültige Antwort sowie URL bereit, nicht jeden einzelnen Sprung. Das Tool sendet außerdem keine Browser-Cookies. Eine API kann ihre Antwort anhand von Cookies, Ursprung oder anderen browsergesteuerten Headern verändern.

Ja, wenn der Endpunkt die daraus entstehende CORS-Anfrage zulässt. Authorization-Werte werden direkt an den Endpunkt gesendet. Im Schrittmodus bleiben die Felder nur bis zum Laden von Schritt 2 vorübergehend in diesem Tab und werden dann aus dem Sitzungsspeicher gelöscht; unser Server erhält sie nicht. Verwenden Sie keine produktiven Geheimnisse für nicht vertrauenswürdige Endpunkte.

Der Timer läuft in Ihrem Browser vom Start von Fetch bis zum Eintreffen der Antwortheader. Darin stecken Browser- und Netzwerkaufwand, während Serverlogs oft nur die Anwendungsverarbeitung messen. Der Download des Inhalts zählt nicht dazu; vergleichen Sie mehrere Prüfungen im selben Browser und Netzwerk.

Nein. Dieser Prüfer verwendet Browser-Fetch für gewöhnliche HTTP- und HTTPS-Anfragen. WebSocket und gRPC benötigen protokollspezifische Clients und werden hier nicht getestet.

Verwandte Tools