Я уже много рассказывал об этой теме, читал различные статьи об этом заголовке, о его использовании на Heroku или о проектах на основе Django.
Тем не менее, он все еще запутался в моей голове.
Когда вы работаете с веб-сервисом, к которому обращаются клиенты, может быть сложно сопоставить запросы (которые клиент видит) с журналами сервера (что может видеть сервер).
Идея X-Request-ID заключается в том, что клиент может создать некоторый случайный идентификатор и передать его на сервер. Затем сервер включает этот идентификатор в каждый созданный им оператор журнала. Если клиент получает сообщение об ошибке, он может включать идентификатор в отчете об ошибке, позволяя оператору сервера искать соответствующие операторы журнала (без необходимости полагаться на отметки времени, IP-адреса и т.д.).
Поскольку этот идентификатор создается (случайно) клиентом, он не содержит конфиденциальной информации и, следовательно, не должен нарушать конфиденциальность пользователя. Поскольку уникальный идентификатор создается для каждого запроса, он также не помогает пользователям отслеживания.
Цель: идемпотентность
С идентификатором, который изменяется для каждого запроса, но остается неизменным в случае повторной попытки запроса, получатель может убедиться, что запрос не будет обработан более одного раза.
Это цитата из некоторого провайдера API:
Все HTTP-запросы POST, PUT и PATCH должны содержать уникальный заголовок X-Request-Id, который используется для обеспечения идемпотентной обработки сообщения в случае повторной попытки.
Если вы сделаете случайную строку, уникальную для каждого запроса, это не нарушит вашу конфиденциальность и не включит отслеживание.
Ваш интернет работает (как обычно), поэтому вы звоните в Tellstra и ждете по телефону вечно... наконец, вы сдаетесь и расстроенно хлопаете телефоном. (Это неудачный вызов. И в журнале вызовов Tellstra есть запись об этом.)
"Вот оно, я звоню омбудсмену!"
Но у Обмудсмана есть тысячи записей вызовов (все неудавшиеся запросы Tellstra). Если вы скажете им, что позвонили в Telstra, и что ваш звонок был неудачным, этого будет недостаточно: как омбудсмен узнает из всех записей звонков Tellstra, какой из них был вашим, чтобы его можно было продолжить расследовать??
Именно там, где приходит X-Request-ID - когда вы звоните в Tellstra, вы передаете случайное число (X-Request-ID), и это записывается в записи Tellstra. Таким образом, омбудсмен (имеющий доступ ко всем записям) сможет найти ваш входящий звонок и выяснить, что пошло не так.
То же самое относится и к http-запросам - это идентификатор, используемый для того, чтобы помочь вам (как внутреннему разработчику) выяснить, что пошло не так, когда клиент выдаст вам ошибку или большой отчет.
Это основное резюме этого. Любые вопросы и т.д. просто оставьте комментарий, и я надеюсь прояснить его.
Этот заголовок запроса может использоваться для синхронизации. Скажем, вы создали список ToDo, который предлагает автономные возможности. Ваш пользователь создает 3 элемента, и каждому из них предоставляется уникальный UUID в автономном приложении. Когда доступ к сети доступен, записи отправляются на сервер и возвращаются соответствующие идентификаторы, автоматически генерируемые из базы данных. Затем вы можете заменить идентификаторы в своем приложении (например, атрибут "id" элемента HTML "li" ).