Journal Création d'un web-service de type REST en Opa

Posté par  .
Étiquettes :
11
7
sept.
2012

Bonjour à tous,

je viens de publier sur Github un petit tutoriel sur la gestion en Opa des requêtes HTTP de type REST et permettant de montrer comment Opa se compare à d'autres frameworks facilitant le développement de services RESTful en JavaScript.

Pour ce faire, j'ai écrit une petite application permettant de traiter des requêtes REST telles que POST, PUT, DELETE et GET et de manipuler des ressources en conséquence.

Voici le début du tutoriel (par soucis de place je ne l'ai pas mis en entier).
La suite est disponible à l'adresse http://gregmak.github.com/.

Pre-requis.

Vous devez bien sûr installer Opa, téléchargeable directement depuis le site d'opalang, ou depuis le repo github d'opalang.

Uns fois Opa téléchargé et installé, vous devriez avoir tout ce dont vous avez besoin. Il n'y a pas d'autres dépendances à installer (Node.js étant automatiquement installé par Opa s'il n'est pas détecté durant la phase de configuration).

Le squelette de l'application.

Opa est livré avec un outil permettant de générer un squelette d'application basé sur le modèle MVC.

Ouvrez une console, placez vous à l'endroit souhaité et tapez simplement

opa create snippets

snippets est le nom de notre application.

Cela va créer un répertoire snippets comprenant le squelette de notre application (pour plus de détails sur cet outil, regardez l'article de Cédric Soulas sur le blog d'opalang).

La configuration.

Un fichier nommé opa.conf est placé à la racine de l'application et décrit les importations nécessaires pour chaque fichier, que ce soit l'importation d'éléments de la librairie standard d'Opa ou d'un des autres fichiers source de l'application. Éditez ce fichier et modifier-le comme ceci :

snippets.controller:
    import snippets.view
    import snippets.model // nouvelle ligne ajoutée
    src/controller.opa

snippets.view:
    import snippets.model
    import stdlib.themes.bootstrap
    src/view.opa

snippets.model:
    src/model.opa

En ajoutant la ligne import snippets.model, nous avons indiqué au compilateur que le module Controller du fichier src/controller.opa a besoin de connaître certaines fonctions définies dans le module Model du fichier src/model.opa.

Notez que ces déclarations peuvent aussi bien se faire en début de chaque fichier. Mais l'utilisation d'un fichier opa.conf a l'avantage de centraliser toutes les déclarations de ce type.


Voila, c'était juste le début du tutoriel. Le tutoriel complet est disponible à l'adresse http://gregmak.github.com/.

  • # Opa ?

    Posté par  . Évalué à 10.

    Opa gangnam style !

    BeOS le faisait il y a 20 ans !

  • # Scrunieunieu et grumgrum

    Posté par  (site web personnel) . Évalué à 3.

    Hello,

    Tu vas peut-être me traiter de "cheuteumeuleur php-iste grabataire"… Il n'empêche que je me pose des questions quand à la pertinence de faire du REST en javascript. Personnellement j'utilise le JS avec beaucoup de parcimonie, car la compatibilité des navigateurs n'est pas toujours au rendez-vous, et aussi (surtout?) parce qu'il peux être tripatouillé coté client.

    Je te concède qu'à l'époque des smartphones et web-app, le duo html5-JS fait fureur et donne des trucs super sexy. Mais faire appel à des webservice en JS fait tilter des vieux réflexes du genre : "pas de vérification de formulaire coté client". Sur des requêtes de récupération de contenu, pas de soucis, le bidouilleur se pourri lui-même, mais pour tout ce qui est écriture, mise à jour, oula, oulaaa……
    Je vois déjà venir la réponse : et AJAX alors ? Ben justement j'ai un avis plutôt tranché et pas vraiment partisan …
    Grabataire je te dis !

    Autre point, et pas des moindres, en général les services REST sont plutôt en infrastructure, en interne, et on ne les expose pas en frontal au REST du monde ( facile celle là ). Ceci bien souvent parce que c'est reconnue qu'en termes de sécurité c'est pas la panacée, ou alors faut avoir passé un temps conséquent et bien sérieux à blinder…

    Fuse : j'en Use et Abuse !

    • [^] # Re: Scrunieunieu et grumgrum

      Posté par  . Évalué à 3.

      Rassure moi, c'est un troll ?

    • [^] # Re: Scrunieunieu et grumgrum

      Posté par  . Évalué à 3.

      Node.js (et donc Opa), c'est du JS côté serveur!

    • [^] # Re: Scrunieunieu et grumgrum

      Posté par  . Évalué à 2.

      Autre point, et pas des moindres, en général les services REST sont plutôt en infrastructure, en interne, et on ne les expose pas en frontal au REST du monde

      Ya quelques petites startup assez osees qui commencent a s'y tenter.
      Faïssebouc je crois.
      Et touiteur. Ou naiteflisque.
      Mais touiteur en revient, apparement ca a pas trop marche pour eux.

      Exposer api.maboite.com ne veut pas dire router directement le traffic public dans ton backend, t'as generalement un front facing qui s'occupe de babiole du genre authentification et validations de donnees avant de pousser au backend…

      Linuxfr, le portail francais du logiciel libre et du neo nazisme.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.