Pourquoi CoAP ( Constrained Application Protocol) ?
Les principes REST avec leur représentation de l'information par des ressources pointées par des
identifiants globalement unique est une des clés du succès de l'Internet et de la composition de
services distribués. Même si ce n'est pas l'unique solution, il est indispensable que les informations
provenant d'objets contraints puissent s'intégrer dans cette toile d'araignée mondiale. CoAP, pour
Contraint Application Protocol, permet cette intégration à un meilleur coût en termes d'empreinte
mémoire ou protocolaire que ne le permettrait le protocole HTTP.
CBOR permet d’envoyer des données structurées de manière efficace, que le récepteur peut faire
la différence entre un entier ou une chaîne de caractères et également savoir combien d’éléments
composent un dictionnaire ou un tableau. En plus d’un gain de place par rapport à JSON, la
complexité pour sérialiser ou désérialiser est limitée, conduisant à des implémentations peu
gourmandes en mémoire.
Mais CBOR n’est pas suffisant pour une bonne interopérabilité. Quand un récepteur reçoit les
données, il faut qu'il sache qu’il s’agit d’un codage CBOR et pas d'une autre structure. De plus, il
faut que le récepteur sache quoi faire de ces données. Dans le TP précédent, nous avons transmis
des séries temporelles correspondant à des relevés de température. Mais si nous voulions
également transmettre l’humidité et la pression, comment le récepteur ferait la différence ?
Nous avons une solution pour répondre à ces questions : l’utilisation de ressources.
Nous avons vu qu’avec le paradigme REST, les ressources étaient nommées. Donc,
pour distinguer les différentes séries temporelles, il suffit d’utiliser un nom (ou un URI) différent.
Les ressources contiennent également des méta-informations et il est donc possible de transporter
le format de codage pour indiquer qu’il s’agit de CBOR, de JSON, de CSV...
Malgré son universalité, ce modèle pose un problème pour les objets contraints :
• HTTP utilise TCP pour fiabiliser les communications entre le client et le serveur. Or, TCP
est gourmand en ressources. Il faut de la mémoire pour stocker les paquets non acquittés ou
hors séquence, un grand nombre d’heuristiques doivent être mises en œuvre pour améliorer
ses performances ;
• la souplesse pour créer des en-têtes peut s'avérer être un désavantage pour un objet
contraint. Ainsi, la requête HTTP vers le serveur [Link] peut avoir cette
forme :
GET / HTTP/1.1\ r \n
Host: [Link]\r\n
User−Agent: Mozilla/5.0 (X11;Ubuntu;Linuxx8664;rv:25.0) Gecko
/20100101Firefox/25.0\ r\n
Accept:text/html,application/xhtml+xml,application/xml;q=0.9,∗/∗;q=0.8\r\n
Accept−Language: en−US,en;q=0.5\r\n
Accept−Encoding:gzip,deflate\r\n
Connection: keep-alive\r\n
\r \n
En dessous de la première ligne qui demande la ressource à la racine (généralement [Link]),
on trouve un certain nombre de lignes sous le format :
Nom du champ : valeur du champ\r\n
qui vont indiquer au serveur le nom du serveur que l’on veut atteindre, la description du navigateur
et les formats que celui-ci peut accepter.
Le but de CoAP est de définir un protocole beaucoup plus strict qui sera donc plus facile à mettre
en œuvre mais qui pourra interopérer avec HTTP afin de préserver les principes définis par
l’architecture REST et profiter du nommage des ressources pour que les ressources contraintes
participent à la grande toile d'araignée mondiale.
Représentation des données
Pour que le client puisse interpréter les données, il faut qu’il puisse comprendre comment elles
sont représentées. Cela peut dépendre de la police de caractères. Ainsi, une lettre accentuée ne sera
pas représentée de la même manière suivant le type de code. Il en va de même pour la
représentation. Le plus simple consiste à envoyer en ASCII la valeur demandée, par exemple la
chaîne de caractères 18 indique 18 degrés. Il faut donc indiquer le type de codage/sérialisation
utilisé pour décrire le contenu de la ressource. Là où HTTP utiliserait un nom, c'est-à-dire une
chaîne de caractères, CoAP va utiliser une valeur numérique.
Le tableau suivant donne un extrait des valeurs utilisées pour représenter les formats. La liste complète
peut être trouvée sur le site de l'IANA [Link]
[Link]#content-formats.
HTTP CoAP Signification
text/plain ; charset=utf-8 0 Valeur par défaut
application/link-format 40 Description des caractéristiques d'un objet
application/json 50 Ressource au format JSON
application/cbor 60 Ressource au format CBOR
Mesures de capteur au format SenML
application/senml+json 110
codé en JSON
Mesures de capteur au format SenML
application/senml+cbor 112
codé en CBOR
Tâches à faire :
Regardez les vidéos mentionnées sur la classroom (CoAP, MID, Tocken et la représentation des
URI)
Cherchez sur le net plus de détails sur CoAP si nécessaire.