Что принадлежит в заголовке HTTP-запроса против тела запроса?

Я работаю над набором веб-сервисов для мобильного клиента, и требования требуют, чтобы уникальный идентификатор устройства был включен во все запросы, сохранялся в определенных запросах и использовался для фильтрации результатов в других.

Было предложено поместить его в настраиваемый заголовок HTTP, поскольку он будет включен во все запросы, поэтому я начал задаваться вопросом, какие критерии можно использовать для определения того, принадлежит ли данный фрагмент данных в заголовок или наряду с другими данными в тело запроса.

Есть ли такие критерии?

Когда информация важна, вы должны поместить ее в организм.

Почему?

1. прокси-серверам разрешено изменять заголовки. Многие настроены на удаление любых заголовков, которые они не знают. Это, однако, применимо только при использовании незашифрованного HTTP. Когда вы используете HTTPS, прокси не может изменить заголовки, потому что они зашифрованы.
2. Когда вы используете веб-сервис, вы обычно делаете это для взаимодействия с другими устройствами, сервисами и инструментами. Большинство API и инструментов, которые работают с веб-сервисами, могут легко изменять запросы, но многие затрудняют или даже делают невозможным добавление пользовательских заголовков. Это, конечно, применимо только тогда, когда речь идет о совместимости. Но когда вам все равно, вы можете спросить себя, почему вы используете веб-сервисы в первую очередь вместо того, чтобы просто строить свой собственный протокол на сыром TCP.

Хотя строка несколько размыта, для меня эмпирическое правило таково: данные, над которыми работает ваша бизнес-логика, должны быть в теле, метаданные могут / должны быть помещены в заголовки.

Другой способ взглянуть на это: данные, которые появляются только в определенных видах запросов, должны быть в теле, а данные, которые обрабатываются последовательно во всем приложении, должны попадать в заголовки.

Еще одна точка зрения такова: можете ли вы представить, что часть данных обрабатывается глобально, например, маршрутизатором / брандмауэром, а не вашим приложением? Если да, то, вероятно, он должен идти в заголовках, а не в теле.

Вот некоторые примеры применения этих правил:

• Учетные данные безопасности помещаются в заголовки, поскольку, скорее всего, они будут обрабатываться одинаково во всех местах приложения; на уровне реализации, вероятно, будет какой-то фильтр запросов, отклоняющий запросы без действительных учетных данных, независимо от фактической конечной точки, обрабатывающей запрос в случае, если он действительно проходит через фильтр.
• Если, с другой стороны, у вас есть конечная точка, которая позволяет администратору добавлять пользователей в вашу систему, логин создаваемого пользователя должен быть в теле запроса, поскольку: а) он обрабатывается бизнес-логикой вашего приложения, б) это появляется в этой конкретной конечной точке, но не в других.
• Опции, которые управляют кэшированием, могут хорошо вписываться в заголовки (если только кэширование не является основной частью бизнес-логики вашего приложения).

Возвращаясь к вашему вопросу об уникальном идентификаторе устройства: если оно используется повсеместно, например, только для ведения журнала, его можно поместить в заголовки. Но если он используется для фильтрации запросов по-разному в зависимости от конечной точки, он лучше будет в теле. Конечно, если у вас есть оба варианта использования, вероятно, лучше придерживаться только одного способа его передачи (возможно, заголовков), а не заставлять пользователя API размещать одни и те же данные в двух местах, что дает вам дилемму того, противоречивые входные данные или осуществление некоторой проверки.

Содержание клиентского запроса; который не будет изменяться при множественных запросах к одному и тому же серверу, будет частью HEADER, например, учетные данные, другие, которые часто изменяются на запрос, будут частью BODY.

ИЛИ ЖЕ

свойство содержимого сообщения / тела перейдет в заголовок. например, тип кодирования, длина контента, тип контента.

А ТАКЖЕ

В вашем случае подобные параметры фильтра должны быть добавлены в качестве параметров запроса / запроса в URL.

/mobiles?type=MOTO&colour=black

В остальных сервисах URL-адрес сам по себе будет ссылаться на объект

/conferences/{conference_id} -> относится к конкретной конференции