Aller au contenu principal

5. Request/Response Semantics (Sémantique Requête/Réponse)

CoAP fonctionne selon un modèle requête/réponse similaire à HTTP : un point de terminaison CoAP dans le rôle de "client" envoie une ou plusieurs requêtes CoAP à un "serveur", qui traite les requêtes et envoie des réponses CoAP. Contrairement à HTTP, les requêtes et les réponses ne sont pas envoyées via une connexion précédemment établie, mais sont échangées de manière asynchrone via des datagrammes CoAP.

5.1. Requests (Requêtes)​

Une requête CoAP consiste en une méthode à appliquer à une ressource, un identifiant de la ressource, une charge utile et un type de média Internet (le cas échéant), ainsi que des métadonnées optionnelles sur la requête.

CoAP prend en charge les méthodes de requête de base GET, POST, PUT et DELETE, qui sont facilement mises en correspondance avec HTTP. Elles ont également les propriétés de sécurité (Safe) et d'idempotence (Idempotent) définies dans HTTP.

5.1.1. Method Definitions (Définitions des Méthodes)​

Dans cette section, nous définissons les méthodes CoAP.

  • GET : La méthode GET récupère une représentation de l'information qui correspond actuellement à la ressource identifiée par l'URI de la requête.
  • POST : La méthode POST demande que la représentation incluse dans la requête soit traitée par la ressource identifiée par l'URI de la requête.
  • PUT : La méthode PUT demande que la ressource identifiée par l'URI de la requête soit mise à jour ou créée avec la représentation incluse dans la requête.
  • DELETE : La méthode DELETE demande que la ressource identifiée par l'URI de la requête soit supprimée.

5.2. Responses (Réponses)​

Après avoir reçu et interprété une requête, un serveur répond par une réponse CoAP qui est mise en correspondance avec la requête au moyen d'un jeton (Token) généré par le client.

Une réponse est identifiée par un Code de Réponse (Response Code), qui est analogue au Code d'État HTTP. Les codes de réponse indiquent le résultat de la tentative de compréhension et de satisfaction de la requête.

5.2.1. Response Code Definitions (Définitions des Codes de Réponse)​

Les codes de réponse sont regroupés en classes :

  • 2.xx (Succès) : La requête a été reçue, comprise et acceptée avec succès.
  • 4.xx (Erreur Client) : La requête contient une syntaxe incorrecte ou ne peut pas être satisfaite.
  • 5.xx (Erreur Serveur) : Le serveur n'a pas réussi à satisfaire une requête apparemment valide.

5.3. Request/Response Matching (Correspondance Requête/Réponse)​

Quelle que soit la manière dont une réponse est envoyée (par exemple, dans un message d'accusé de réception ou un message confirmable séparé), elle est mise en correspondance avec la requête par le Jeton (Token) inclus par le client dans la requête. Le jeton doit être unique pour la paire source/destination donnée pendant la durée de vie de l'échange.

5.4. Options (Options)​

CoAP définit un certain nombre d'options qui peuvent être incluses dans une requête ou une réponse. Les options fournissent des métadonnées supplémentaires, telles que le format du contenu, l'hôte cible, ou des balises d'entité (ETags) pour la validation du cache.

5.5. Payload (Charge Utile)​

Les requêtes et les réponses CoAP peuvent inclure une charge utile. La charge utile est la représentation de la ressource (pour une réponse GET ou une requête PUT) ou les données à traiter (pour une requête POST). Le format de la charge utile est spécifié par l'option Content-Format.

5.6. Caching (Mise en Cache)​

CoAP prend en charge la mise en cache des réponses pour réduire le trafic réseau et la latence. Le modèle de mise en cache est similaire à celui de HTTP, utilisant des indicateurs de fraîcheur (Max-Age) et de validation (ETag).

5.7. Proxying (Mise en Proxy)​

CoAP est conçu pour permettre une mise en proxy efficace. Les proxys peuvent être utilisés pour mettre en cache les réponses, effectuer une traduction de protocole (par exemple, CoAP vers HTTP), ou relayer les messages vers d'autres réseaux.

5.8. Method Definitions (Définitions des Méthodes) - Détails​

  • GET : Sûre et idempotente.
  • POST : Ni sûre ni idempotente.
  • PUT : Idempotente mais non sûre.
  • DELETE : Idempotente mais non sûre.

5.9. Response Code Definitions (Définitions des Codes de Réponse) - Détails​

  • Created (2.01) : Comme HTTP 201 Created.
  • Deleted (2.02) : Comme HTTP 204 No Content (mais spécifique à DELETE).
  • Valid (2.03) : Comme HTTP 304 Not Modified.
  • Changed (2.04) : Comme HTTP 204 No Content (mais spécifique à POST/PUT).
  • Content (2.05) : Comme HTTP 200 OK.
  • Bad Request (4.00) : Comme HTTP 400 Bad Request.
  • Unauthorized (4.01) : Comme HTTP 401 Unauthorized.
  • Bad Option (4.02) : L'une des options de la requête n'est pas prise en charge.
  • Forbidden (4.03) : Comme HTTP 403 Forbidden.
  • Not Found (4.04) : Comme HTTP 404 Not Found.
  • Method Not Allowed (4.05) : Comme HTTP 405 Method Not Allowed.
  • Not Acceptable (4.06) : Comme HTTP 406 Not Acceptable.
  • Precondition Failed (4.12) : Comme HTTP 412 Precondition Failed.
  • Request Entity Too Large (4.13) : Comme HTTP 413 Request Entity Too Large.
  • Unsupported Content-Format (4.15) : Comme HTTP 415 Unsupported Media Type.
  • Internal Server Error (5.00) : Comme HTTP 500 Internal Server Error.
  • Not Implemented (5.01) : Comme HTTP 501 Not Implemented.
  • Bad Gateway (5.02) : Comme HTTP 502 Bad Gateway.
  • Service Unavailable (5.03) : Comme HTTP 503 Service Unavailable.
  • Gateway Timeout (5.04) : Comme HTTP 504 Gateway Timeout.
  • Proxying Not Supported (5.05) : Le serveur est un proxy mais ne prend pas en charge l'URI de proxy demandé.
Dernière mise à jour le