Cela fait plus d'une décennie que l'on parle d’Ubiquitous Computing ou d'Internet des objets (depuis près de trois décennies pour le premier). À l'époque, c'était plus ou moins un rêve. Aujourd'hui, c'est une réalité, la plupart d'entre nous étant à chaque instant entourés de plusieurs appareils capables de se connecter à Internet. Un gros travail a été fait récemment par certains groupes de normalisation (par exemple, l'IETF) sur divers aspects touchant l'Internet des objets (IoT : Internet of Things), dont entre autres le protocole Concise Binary Object Representation (CBOR) (comment faire entrer le plus de données possible dans un échange de message aussi petit que possible).
Concise Binary Object Representation (CBOR) est un format de données dont les objectifs de conception rendent possibles un code de taille extrêmement restreinte et un message de taille la plus petite possible et permettent de bénéficier d'extensibilité sans nécessiter de négociation de version. Ces objectifs de conception le démarquent des sérialisations binaires antérieures, telles que ASN.1 et MessagePack.
Mais ce n'était qu'une question de temps avant que REST soit appliqué à ce domaine. Le groupe de travail Environnements Contraints RESTful (CoRE : Constrained RESTful Environments) est mandaté par l'IETF pour fournir :
[...] Un Framework pour applications Orientées Ressources destinées à fonctionner sur des réseaux IP contraints. Un réseau IP contraint impose des limites sur la taille des paquets, peut impliquer un degré élevé de pertes de paquets et un nombre significatif de ses équipements peuvent être éteints à tout moment et périodiquement « réveillés » pour de courtes périodes de temps.
Dans le cadre de ce Framework de construction d'applications sur équipements contraints, le groupe de travail définira également le protocole Constrained Application Protocol (CoAP) pour la manipulation des ressources sur ces équipements :
Le groupe de travail définira une correspondance entre CoAP et une API HTTP REST. Cette correspondance ne dépendra pas d'une application spécifique. Il faut noter que le proxy n'a pas forcément à être fait à la frontière entre le réseau contraint et le réseau plus général, mais peut être déployé à divers endroits dans le réseau sans contrainte.
Le groupe a déjà défini un certain nombre d'éléments que le protocole doit prendre en charge, dont :
- La capacité à créer, lire, mettre à jour et supprimer une ressource sur un périphérique.
- La capacité à supporter l'envoi de messages en multicast, de façon non fiable, à un groupe d'équipements.
- Il doit fonctionner sur UDP, avec support optionnel (et limité) de TCP.
- Spécification de l'API basée sur HTTP REST et la traduction pour communiquer avec les périphériques.
Étant donné que le groupe vient juste d'être lancé, il y a encore un certain nombre d'inconnues, comme la question de la sécurité par exemple. Toutefois, le projet de support de CoAP en Java est en cours, avec jCoAP.