URL: https://linuxfr.org/news/webinaire-erocci-le-15-mai-2014-decouvrez-le-framework-rest-2-0 Title: Webinaire erocci le 15 mai 2014: découvrez le framework REST 2.0 Authors: Jean Parpaillon Benoît Sibaud, palm123, ZeroHeure, Nÿco et Nils Ratusznik Date: 2014年05月08日T15:43:12+02:00 License: CC By-SA Tags: cloud, rest, erlang et occi Score: 5 erocci est un framework générique [OCCI](http://occi-wg.org/) (Open Cloud Computing) Interface) écrit en Erlang/OTP (Open Telecom Platform, la bibliothèque standard du langage de programmation Erlang). Le standard OCCI est un standard ouvert, défini par l'OpenGridForum, pour définir des API REST autour du _cloud computing_, de manière plus contrainte, et donc facilement interopérables. Plus de détails dans la suite de la dépêche. Et si vous n'avez pas tout compris, mais que cela titille votre curiosité, nous présenterons erocci lors d'un webinaire organisé par OW2 le 15 mai. Vous pourrez y voir erocci tourner en vrai et poser des questions à l'auteur. Les inscription se passent [sur le site d'OW2](http://www.ow2.org/view/Webinars/Presentation_of_erOCCI_new_OW2_project). ---- [Dépêche sur erocci 0.1 en février 2014](http://linuxfr.org/news/le-premier-framework-generique-occi-erocci-0-1) [Groupe de travail OCCI](http://occi-wg.org) [Inscription au webinaire OW2](http://www.ow2.org/view/Webinars/Presentation_of_erOCCI_new_OW2_project) [Site web erocci](http://jeanparpaillon.github.io/erocci/) ---- Au fait, pourquoi [[REST]] ? ======================== Si le cloud computing a adopté les architectures orientées ressource comme paradigme, et les API REST comme technologie, la grande liberté de mise en oeuvre des API REST rend difficile l'interopérabilité entre ces différentes API: le typage des ressources, le format même des données (JSON, XML, text, etc) n'est pas défini par REST. Et les standards, n'y en a-t-il pas déjà pléthore ? =================================================== Les nombreux standards existants dans le cloud se limitent à fixer un format de données et un vocabulaire pour un domaine particulier: IaaS, authentification, etc. Le standard [OCCI](http://occi-wg.org) adopte, à cet égard, une approche différente puisqu'il définit un méta-modèle ou pour faire simple, une manière unique de typer les ressources et d'exprimer des relations entre elles. Ensuite, OCCI définit une manière unique de le représenter dans les formats de données les plus courants et de les transporter sur différents protocoles réseau : HTTP, XMPP, etc. Ok pour OCCI, mais quid d'erocci ? ================================== erocci est une mise en oeuvre de OCCI complètement générique. Le modèle (les types de ressource) est décrit avec un fichier XML et peut donc être échangé avec d'autres mises en oeuvre. Ensuite, le développeur devra juste choisir un _listener_ (un protocole réseau) parmi HTTP, HTTPS ou XMPP et un _backend_ pour stocker ses objets. Aujourd'hui le seul backend disponible est basé sur [mnesia](http://www.erlang.org/doc/man/mnesia.html), la base de données distribuée de Erlang. Cependant, l'API pour développer un backend erocci est aussi simple que mettre en oeuvre les opérations [CRUD](https://fr.wikipedia.org/wiki/CRUD). erocci est écrit en Erlang pour la stabilité, la montée en charge et la performance. Néanmoins, si vous utilisez un backend existant, aucune ligne de Erlang n'est nécessaire pour développer sa propre API REST. Plusieurs backends peuvent être utilisés en même temps dans erocci. Les backends s'attachent comme un système de fichier dans l'arborescence du serveur. Grâce à Erlang, les requêtes vers plusieurs backends s'effectuent en parallèle, avec gestion des pannes (NdM: d'après la [documentation](http://jeanparpaillon.github.io/erocci/documentation/configuration.html), un backend est considéré comme hors service après un délai configurable). La feuille de route ========== Le projet, bien que jeune, est déjà fonctionnel même si la feuille de route est bien remplie: - gestion des droits, unifiée entre HTTP et XMPP et potentiellement extensible à d'autres protocoles ; - intégration avancée de XMPP pour la gestion des groupes, de la présence, etc. - développement d'un _listener_ XMPP comme composant XMPP : aujourd'hui le _listener_ XMPP est un client XMPP mais les composants XMPP permettraient de faciliter le développement de passerelles entre OCCI et d'autres API.

AltStyle によって変換されたページ (->オリジナル) /