Qu'est-ce qui appartient à un en-tête de demande HTTP par rapport au corps de la demande?
Je travaille sur un ensemble de services Web pour un client mobile, et les exigences exigent qu'un identifiant d'appareil unique soit inclus avec 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, j'ai donc commencé à me demander quels critères pourraient être utilisés pour déterminer si une donnée donnée appartient à un en-tête ou avec d'autres données dans l'organisme de demande.
Existe-t-il de tels critères?
Lorsque l'information est importante, vous devez la mettre dans le corps.
Pourquoi?
- 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. Cependant, cela ne s'applique que lorsque vous utilisez HTTP non chiffré. Lorsque vous utilisez HTTPS, le proxy ne peut pas modifier les en-têtes car ils sont chiffrés.
- Lorsque vous utilisez un service Web, vous le faites généralement pour l'interopérabilité avec d'autres appareils, services et outils. La plupart des API et des outils qui fonctionnent avec les 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 un problème. Mais quand vous ne vous en souciez pas, vous voudrez peut-être vous demander pourquoi vous utilisez les services Web en premier lieu au lieu de simplement construire votre propre protocole sur TCP brut.
Bien que la ligne soit quelque peu floue, pour moi, une règle de base 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 être dans le corps tandis que les données qui sont traitées de manière cohérente dans l'ensemble de l'application doivent aller dans les en-têtes.
Un autre point de vue est: pouvez-vous imaginer qu'un élément de données est traité à l'échelle mondiale, 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é entrent 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 les demandes sans informations d'identification valides, quel que soit le point de terminaison réel qui gère la demande au cas où il passerait par le filtre.
- Si, en revanche, vous avez un point de terminaison qui permet à un administrateur d'ajouter des utilisateurs à votre système, la connexion de l'utilisateur à créer doit être dans le corps de la demande car: a) il est géré par la logique métier de votre application, b) il apparaît dans ce point final particulier mais pas dans d'autres.
- Les options qui contrôlent la mise en cache peuvent bien s'insérer dans les en-têtes (sauf si la mise en cache fait partie intégrante de la logique métier de votre application).
Revenons à votre question sur l'identifiant unique de l'appareil: s'il est utilisé de manière cohérente partout, par exemple uniquement pour la journalisation, il peut être mis dans les en-têtes. Mais s'il est utilisé pour filtrer les demandes de différentes manières selon le point de terminaison, il serait préférable qu'il soit dans le corps. Bien sûr, si vous avez les deux cas d'utilisation, il est probablement préférable de s'en tenir à une seule façon de les transmettre (probablement les en-têtes) plutôt que de forcer 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émentant une sorte de validation.
Le contenu de la demande du client; qui ne sera pas modifié sur plusieurs demandes adressées au même serveur fera partie de HEADER, par ex. les informations d'identification, d'autres qui sont fréquemment modifiées par demande feront partie de BODY.
OR
la propriété du contenu du message/corps ira dans l'en-tête. par exemple) type de codage, longueur du contenu, type de contenu.
ET
Dans votre cas, des paramètres de filtre similaires devraient être ajoutés en tant que paramètres de requête/demande 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