Ya busqué en Google mucho este tema, leí varios artículos sobre este encabezado, su uso en Heroku y proyectos basados en Django.
Sin embargo, todavía está todo confuso en mi cabeza.
Respuestas:
Cuando opera un servicio web al que acceden los clientes, puede resultar difícil correlacionar las solicitudes (que un cliente puede ver) con los registros del servidor (que el servidor puede ver).
La idea X-Request-IDes que un cliente puede crear una identificación aleatoria y pasarla al servidor. Luego, el servidor incluye ese ID en cada declaración de registro que crea. Si un cliente recibe un error, puede incluir la ID en un informe de error, lo que permite al operador del servidor buscar las declaraciones de registro correspondientes (sin tener que depender de marcas de tiempo, IP, etc.).
Como esta identificación es generada (aleatoriamente) por el cliente, no contiene ninguna información sensible y, por lo tanto, no debe violar la privacidad del usuario. Como se crea una identificación única por solicitud, tampoco ayuda con el seguimiento de los usuarios.
Propósito: idempotencia
Con un ID que cambia para cada solicitud, pero que permanece igual en caso de que se vuelva a intentar una solicitud, el receptor puede asegurarse de que la solicitud no se procese más de una vez.
Esta es una cita de algún proveedor de API:
Todas las solicitudes HTTP POST, PUT y PATCH deben contener un encabezado X-Request-Id único que se utiliza para garantizar el procesamiento de mensajes idempotentes en caso de un reintento
Si lo convierte en una cadena aleatoria, única por solicitud , no infringirá su privacidad ni permitirá el seguimiento.
Si desea saber más de lo que la idempotencia tiene para ofrecer, lea este artículo revelador .
NB Como comenta Stefan Kögl, este encabezado no está estandarizado, de ahí el prefijo "X-" (obsoleto).
Tu Internet está funcionando (como de costumbre), así que llamas a Tellstra y estás esperando en el teléfono para siempre ... finalmente te rindes y cierras el teléfono con frustración. (Esta es una llamada fallida. Y hay un registro de ella en los registros de llamadas de Tellstra).
"¡Eso es, estoy llamando al Defensor del Pueblo!"
Pero el Obmudsman tiene miles de registros de llamadas que revisar (todas las consultas fallidas de Tellstra). Si les dice que llamó a Telstra y que su llamada no tuvo éxito, eso no será suficiente: ¿cómo sabrá el Defensor del Pueblo, de todos los registros de llamadas de Tellstra, cuál era el suyo, para que se pueda investigar más a fondo? ?
Ahí es donde entra X-Request-ID: cada vez que llama a Tellstra, pasa un número aleatorio (el X-Request-ID) y esto se registra en los registros de Tellstra. De esa manera, el ombudsman (que tiene acceso a todos los registros) podrá encontrar su llamada entrante para averiguar qué salió mal.
Lo mismo se aplica a las solicitudes http: es una identificación que se usa para ayudarlo (como desarrollador de back-end) a descubrir qué salió mal cuando un cliente le emite un error o un informe grande.
Ese es el resumen básico de la misma. Cualquier pregunta, etc., solo publique un comentario y espero aclararlo.
Este encabezado de solicitud se puede utilizar para la sincronización. Supongamos que ha creado una lista de tareas pendientes que ofrece capacidad sin conexión. Su usuario crea 3 elementos y cada uno de ellos recibe un UUID único en la aplicación fuera de línea. Cuando la conectividad de la red está disponible, los registros se envían por POST al servidor y se devuelven los ID correspondientes generados automáticamente a partir de la base de datos. A continuación, puede reemplazar los ID en su aplicación (por ejemplo, el atributo "id" del elemento HTML "li").