Qu'est-ce qui appartient à un en-tête de requête HTTP par rapport au corps de la requête?

Je travaille sur un ensemble de services Web pour un client mobile, et les exigences exigent qu'un identifiant de périphérique unique soit inclus dans toutes les demandes, stocké dans certaines demandes et utilisé pour filtrer les résultats dans d'autres.

Il a été suggéré de le placer dans un en-tête HTTP personnalisé, car il sera inclus dans toutes les demandes. Je me suis donc demandé quels critères pourraient être utilisés pour déterminer si une donnée donnée appartient à un en-tête ou à d'autres données dans le corps de la demande.

Existe-t-il de tels critères?

Lorsque l'information est importante, vous devriez la mettre dans le corps.

Pourquoi?

1. les serveurs proxy sont autorisés à modifier les en-têtes. Beaucoup sont configurés pour supprimer les en-têtes qu'ils ne connaissent pas. Ceci, cependant, ne s'applique que lorsque vous utilisez HTTP non crypté. Lorsque vous utilisez HTTPS, le proxy ne peut pas modifier les en-têtes car ils sont chiffrés.
2. Lorsque vous utilisez un service Web, vous le faites généralement pour une interopérabilité avec d'autres appareils, services et outils. La plupart des API et des outils qui fonctionnent avec des services Web peuvent facilement modifier les demandes, mais beaucoup rendent difficile, voire impossible, l'ajout d'en-têtes personnalisés. Ceci, bien sûr, ne s'applique que lorsque l'interopérabilité est une préoccupation. Mais si vous ne vous en souciez pas, vous voudrez peut-être vous demander pourquoi vous utilisez des services Web au lieu de vous contenter de créer votre propre protocole sur du TCP brut.

Bien que la ligne soit un peu floue, pour moi, la règle générale est la suivante: les données sur lesquelles votre logique métier fonctionne doivent être dans le corps, les métadonnées peuvent / doivent être placées dans des en-têtes.

Une autre façon de voir les choses est la suivante: les données qui n'apparaissent que dans des types spécifiques de demandes doivent figurer dans le corps, tandis que les données traitées de manière cohérente dans l'ensemble de l'application doivent être placées dans des en-têtes.

Un autre point de vue est le suivant: pouvez-vous imaginer qu’une donnée soit gérée de manière globale, par exemple par un routeur / pare-feu plutôt que par votre application? Si oui, cela devrait probablement aller dans les en-têtes plutôt que dans le corps.

Voici quelques exemples d'application de ces règles:

• Les informations d'identification de sécurité sont placées dans les en-têtes, car elles seront probablement traitées de la même manière à tous les endroits d'une application. au niveau de la mise en œuvre, il y aura probablement un filtre de demande qui rejettera des demandes sans informations d'identification valides, quel que soit le noeud final traitant la demande au cas où il parviendrait à traverser le filtre.
• Si, par contre, vous avez un noeud final permettant à un administrateur d'ajouter des utilisateurs à votre système, le nom de l'utilisateur à créer doit figurer dans le corps de la requête car: a) il est géré par la logique métier de votre application, b) il apparaît dans ce critère, mais pas dans d'autres.
• Les options qui contrôlent la mise en cache peuvent bien s'intégrer dans les en-têtes (à moins que la mise en cache ne soit une partie essentielle de la logique métier de votre application).

Pour en revenir à votre question sur l'ID de périphérique unique: s'il est utilisé de manière cohérente partout, par exemple uniquement pour la journalisation, il peut être placé dans les en-têtes. Mais s'il est utilisé pour filtrer les demandes de différentes manières en fonction du noeud final, il serait préférable de le placer dans le corps. Bien sûr, si vous avez les deux cas d'utilisation, il est probablement préférable de ne conserver qu'un seul moyen de le transmettre (probablement les en-têtes) plutôt que d'obliger l'utilisateur de l'API à mettre les mêmes données à deux endroits, ce qui vous donne le dilemme de permettre Entrées incohérentes ou implémentation d'une sorte de validation.

Le contenu de la demande du client; HEADER, qui ne changera pas pour plusieurs requêtes adressées au même serveur, fera partie de HEADER, par exemple, les informations d'identification, tandis que d'autres, fréquemment modifiées par requête, feront partie de BODY.

OU

propriété du message / corps du contenu ira dans en-tête. par exemple) type de codage, longueur du contenu, type du contenu.

ET

Dans votre cas, les paramètres de filtre doivent être ajoutés en tant que paramètres de requête / requête dans l'URL.

/mobiles?type=MOTO&colour=black

Dans les services reposants, l'URL elle-même fera référence à un objet

/conferences/{conference_id} -> fait référence à une conférence spécifique