3.1. Sémantique générique

3.1. Sémantique générique

Une grande partie de la valeur de HTTP réside dans sa sémantique générique -- c'est-à-dire que les éléments de protocole définis par HTTP sont potentiellement applicables à chaque ressource et ne sont pas spécifiques à un contexte particulier. Les sémantiques spécifiques à l'application sont mieux exprimées dans le contenu des messages et les champs d'en-tête, pas dans les codes d'état ou les méthodes (bien que les codes d'état et les méthodes aient une sémantique générique qui se rapporte à l'état de l'application).

Cette séparation entre sémantique générique et spécifique à l'application permet de traiter un message HTTP par un logiciel commun (par exemple, serveurs HTTP, intermédiaires, implémentations de clients et caches) sans exiger que ces implémentations comprennent l'application en cours d'utilisation. Elle permet également aux gens de tirer parti de leur connaissance de la sémantique HTTP sans avoir besoin de connaissances spécialisées d'une application particulière.

Par conséquent, les applications qui utilisent HTTP NE DOIVENT PAS redéfinir, affiner ou superposer la sémantique d'éléments de protocole génériques tels que les méthodes, les codes d'état ou les champs d'en-tête existants. Au lieu de cela, elles devraient concentrer leurs spécifications sur les éléments de protocole qui sont spécifiques à leur application -- à savoir, leurs ressources HTTP.

Voir [BCP190] pour plus d'informations.

Lors de la rédaction d'une spécification, il est souvent tentant de spécifier exactement comment HTTP doit être implémenté, pris en charge et utilisé. Cependant, cela peut facilement conduire à un profil involontaire du comportement de HTTP. Par exemple, il est courant de voir des spécifications avec un langage comme celui-ci:

Une requête POST DOIT entraîner une réponse 201 Created.

Cela crée une attente chez le client que la réponse sera toujours 201 Created alors qu'en fait, cette réponse n'est pas du tout certaine. Elle n'est attendue que lorsque le serveur estime qu'une nouvelle ressource a été créée, mais diverses raisons (telles qu'une politique de sécurité) pourraient empêcher le serveur de créer une nouvelle ressource ou de confirmer que la ressource a été créée.

Un langage plus approprié serait:

Une requête POST réussie DEVRAIT entraîner une réponse 201 Created lorsqu'une ressource a été créée.

Une spécification peut utiliser des instances spécifiques d'éléments de protocole pour signaler une sémantique spécifique à l'application. En un sens, c'est ainsi que la sémantique générique est spécialisée pour l'application. Par exemple, une application pourrait définir une requête POST avec un Content-Type spécifique pour signifier "créer une nouvelle ressource avec la représentation jointe". Parce que la sémantique est spécifique à l'application, elle doit être définie dans la spécification de l'application.

Voir Section 4.7 pour les détails sur les champs d'en-tête définis par l'application.