Ich habe dieses Thema bereits viel gegoogelt, verschiedene Artikel über diesen Header, seine Verwendung in Heroku und Projekte gelesen, die auf Django basieren.
Es ist jedoch immer noch alles in meinem Kopf verwirrt.
Antworten:
Wenn Sie einen Webservice betreiben, auf den Clients zugreifen, kann es schwierig sein, Anforderungen (die ein Client sehen kann) mit Serverprotokollen (die der Server sehen kann) zu korrelieren.
Die Idee von X-Request-IDist, dass ein Client eine zufällige ID erstellen und an den Server übergeben kann. Der Server nimmt diese ID dann in jede von ihm erstellte Protokollanweisung auf. Wenn ein Client einen Fehler erhält, kann er die ID in einen Fehlerbericht aufnehmen, sodass der Serverbetreiber die entsprechenden Protokollanweisungen nachschlagen kann (ohne sich auf Zeitstempel, IPs usw. verlassen zu müssen).
Da diese ID (zufällig) vom Kunden generiert wird, enthält sie keine vertraulichen Informationen und sollte daher die Privatsphäre des Benutzers nicht verletzen. Da pro Anforderung eine eindeutige ID erstellt wird, hilft dies auch nicht bei der Verfolgung von Benutzern.
Zweck: Idempotenz
Mit einer ID, die sich für jede Anforderung ändert, aber bei einem erneuten Versuch einer Anforderung gleich bleibt, kann der Empfänger sicherstellen, dass die Anforderung nicht mehr als einmal verarbeitet wird.
Dies ist ein Zitat eines API-Anbieters:
Alle POST-, PUT- und PATCH-HTTP-Anforderungen sollten einen eindeutigen X-Request-ID-Header enthalten, der verwendet wird, um die idempotente Nachrichtenverarbeitung im Falle eines erneuten Versuchs sicherzustellen
Wenn Sie eine zufällige Zeichenfolge festlegen, die pro Anfrage eindeutig ist , wird dies weder Ihre Privatsphäre verletzen noch die Nachverfolgung aktivieren.
Wenn Sie mehr über das Angebot von Idempotenz erfahren möchten, lesen Sie diesen aufschlussreichen Artikel .
NB Wie Stefan Kögl kommentiert, ist dieser Header nicht standardisiert - daher das (veraltete) Präfix "X-".
Ihr Internet läuft (wie üblich), also rufen Sie Tellstra an und warten ewig am Telefon. Schließlich geben Sie auf und knallen das Telefon frustriert auf. (Dies ist ein fehlgeschlagener Anruf. In den Anrufprotokollen von Tellstra ist eine Aufzeichnung davon enthalten.)
"Das war's, ich rufe den Bürgerbeauftragten an!"
Der Obmudsmann muss jedoch Tausende von Anrufdatensätzen durchgehen (alle fehlgeschlagenen Abfragen von Tellstra). Wenn Sie ihnen mitteilen, dass Sie Telstra angerufen haben und Ihr Anruf nicht erfolgreich war, reicht dies nicht aus: Woher weiß der Bürgerbeauftragte aus allen Anruflisten von Tellstra, welche Ihre war - damit sie weiter untersucht werden kann? ?
Hier kommt die X-Request-ID ins Spiel - wenn Sie Tellstra anrufen, geben Sie eine Zufallszahl (die X-Request-ID) weiter, die in den Tellstra-Datensätzen protokolliert wird. Auf diese Weise kann der Ombudsmann (der Zugriff auf alle Datensätze hat) Ihren eingehenden Anruf finden, um herauszufinden, was schief gelaufen ist.
Gleiches gilt für http-Anfragen. Diese ID hilft Ihnen (als Back-End-Entwickler) herauszufinden, was schief gelaufen ist, wenn ein Client Ihnen einen Fehler oder einen großen Bericht ausgibt.
Das ist die grundlegende Zusammenfassung davon. Bei Fragen usw. schreibe einfach einen Kommentar und ich hoffe, ihn zu klären.
Dieser Anforderungsheader kann zur Synchronisierung verwendet werden. Angenommen, Sie haben eine ToDo-Liste erstellt, die Offline-Funktionen bietet. Ihr Benutzer erstellt 3 Elemente, von denen jedes eine eindeutige UUID in der Offline-Anwendung erhält. Wenn eine Netzwerkverbindung verfügbar ist, werden die Datensätze an den Server gesendet und die entsprechenden IDs, die automatisch aus der Datenbank generiert wurden, zurückgegeben. Sie können dann die IDs in Ihrer App ersetzen (z. B. "id" -Attribut des HTML-Elements "li").