Comment exposer un service Web reposant en utilisant Meteor

j'ai fait un plein à écrire sur ce en Meteorpedia:

http://www.meteorpedia.com/read/REST_API

le post passe en revue toutes les 6 options pour créer des interfaces REST, du plus haut niveau (par exemple les paquets intelligents qui gèrent tout pour vous) au plus bas niveau (par exemple écrire votre propre connectHandler).

en outre, les pochettes lors de l'utilisation d'une interface de repos est la bonne ou la mauvaise chose à faire dans Meteor, références Meteor RESTE des outils de test, et explique les pièges les plus courants comme la SCRO les questions de sécurité.

j'ai d'abord répondu à cette question ici , mais pour récapituler:

pour ajouter des méthodes RESTful à vos données, consultez L'API Collection écrite pour Meteor:

https://github.com/crazytoad/meteor-collectionapi

en ce qui concerne l'authentification pour accéder à la base de données, jetez un oeil à ce projet:

https://github.com/meteor/meteor/wiki/Getting-started-with-Auth

les deux sont certainement infantiles en développement, mais vous pouvez créer une API RESTful et l'intégrer avec un client natif mobile assez facilement.

je sais que c'est un vieux fil, mais au cas où quelqu'un trébucherait dessus, j'ai publié un paquet pour écrire APIs de repos dans Meteor 0.9.0+:

https://github.com/kahmali/meteor-restivus

il a été inspiré par RestStop2 et construit avec routeur en fer le routage côté serveur. À mon avis, c'est une meilleure solution que tout ce qui a été posté jusqu'ici.

mise à JOUR: afin De clarifier pourquoi je pense que c'est une "meilleure" solution que de ceux qui sont mentionnés, je me contenterai de souligner les différences entre chacun:

CollectionAPI:

CollectionAPI se limite à exposer les opérations très rudimentaires sur vos collections. Pour mon usage, qui consomme L'API REST dans les applications mobiles, il peut être extrêmement coûteux d'envoyer des documents entiers, et la plupart du temps, j'ai besoin de traiter des données supplémentaires (par exemple, envoyer un message Google Cloud dans un point de départ REST pour ajouter un ami, mais seulement si l'ami est ajouté avec succès). CollectionAPI vous donne un crochet qui s'exécute avant que le point final ne soit exécuté, mais d'après ce que j'ai compris il n'y a rien immédiatement avant la réponse, donc vous n'avez aucun moyen de modifier les données qui sont retournées. Pour l'authentification, CollectionAPI vous permet de définir un authToken qui doit être transmis avec chaque demande. Cela agit plus comme une clé api traditionnelle, car il semble être codé dur dans votre application, et serait donc le même pour chaque utilisateur.

Restivus, puisqu'il n'est pas limité au travail automatisé sur les collections, vous donne le contrôle complet sur vos paramètres. Il fournit maintenant toutes les fonctionnalités incluses dans L'API Collection. Il prend en charge l'authentification de l'utilisateur et les autorisations du rôle, de sorte que vous pouvez identifier l'utilisateur qui fait la demande (et accéder facilement à cet utilisateur à partir de points finaux authentifiés). Il fournit un login et logout endpoint ainsi que pour aider avec cela. Je vais fournir un exemple de code pour Restivus à la fin.

HTTP.publier:

D'après ce que j'ai compris, cela ressemble à CollectionAPI en ce qu'il se limite à exposer les opérations de base de CRUD sur les collections. Celui-ci est plus spécifiquement lié aux Météore de l'édition, et vous permet d'utiliser un publier la fonction pour traiter les requêtes GET. Je suis confus par la documentation, mais il peut ou ne peut pas avoir une authentification de base disponible. Je ne l'ai jamais utilisé avant, mais je ne suis pas un grand fan de L'API pour ça, qui se sent un peu grincheux. Une fois que j'aurai publié plus largement, j'essaierai de le revoir. La même équipe a un autre paquet appelé HTTP.méthodes qui ne vous donnent pas l'accès aux fonctions d'édition, mais qui ont une api similaire à Restivus et, à l'époque, des fonctionnalités similaires.

Restivus est "meilleur" parce qu'il ne vous limite pas à utiliser vos fonctions d'édition, et permet donc un contrôle beaucoup plus fin sur vos paramètres. Si vous cherchez simplement à exposer vos fonctions de publication à une API externe, je vous recommande de vous en tenir à HTTP.publier. Restivus dispose également d'une API plus simple et supporte la méthode HTTP PATCH (dont aucun autre paquet ne semble reconnaître l'existence). Leur HTTP.méthodes paquet est assez similaire à Restivus, sauf qu'il manque de prise en charge du PATCH, et bien qu'il offre une authentification de base, je crois que vous n'avez que la capacité de faire authentifier tous les endpoints, ou aucun. Restivus vous permettra de contrôler cela au niveau d'un point final (pas seulement par route). Les permissions de rôle (par exemple, utilisateur, administrateur) sur les endpoints sont également disponibles sur Restivus, mais je ne vois rien à ce sujet pour HTTP.méthode.

Routeur Meteor:

Cela a été rendu obsolète en faveur de Fer Routeur, veuillez voir ci-dessous.

Routeur En Fer:

Iron Router est génial, mais il n'est pas spécifiquement conçu pour les APIs de repos de construction. Récemment, ils ont ajouté des fonctions correspondant aux méthodes HTTP (GET, POST, etc.).), mais ils ne prennent en charge aucune forme d'authentification, et tout ce à quoi vous avez accès est les objets de requête et de réponse de noeud de niveau inférieur, de sorte que vous serez forcé d'apprendre à travailler avec ceux-ci. Lorsque si vous le faites, vous constaterez qu'il y a du travail répétitif à faire pour chaque paramètre, comme créer des réponses avec les en-têtes et les codes de réponse appropriés. Vous devrez également vous soucier de la conformité à la LCS si votre API est consommée à partir du navigateur.

Restivus est en fait construit sur le dessus du routeur en fer, et fournit une couche d'authentification sur les endpoints. Il supprime également le besoin d'interaction directe avec les objets requête et réponse du noeud, bien qu'ils soient toujours là au cas où on aurait manqué quelque chose. Il utilise donc toute la qualité du routeur en fer avec une API de niveau supérieur pour votre plaisir de codage. Restivus est parfait si vous utilisez déjà Iron Router, car il n'ajoutera aucune dépendance supplémentaire.

RestStop2:

J'utilisais en fait RestStop2 dans un projet sur lequel je travaille quand il a été déprécié en faveur de Iron Router. Ils avaient une bonne documentation, et une API que je préférais. au-dessus des autres. Selon leur suggestion, j'ai construit un nouveau paquet sur le dessus du routeur en fer, qui est très inspiré par RestStop2. Restivus est maintenant approuvé sur la page Github RestStop2, donc je pense qu'ils sont d'accord que c'est un remplacement digne.

voici un petit extrait de code de la section de démarrage rapide du Restivus docs:

if(Meteor.isServer) {
  Meteor.startup(function () {
    // Global configuration
    Restivus.configure({
      useAuth: true,
      prettyJson: true
    });

    // Generates: GET, POST on /api/users and GET, DELETE /api/users/:id for
    // Meteor.users collection
    Restivus.addCollection(Meteor.users, {
      excludedEndpoints: ['deleteAll', 'put'],
      routeOptions: {
        authRequired: true
      },
      endpoints: {
        post: {
          authRequired: false
        },
        delete: {
          roleRequired: 'admin'
        }
      }
    });

    // Maps to: POST /api/articles/:id
    Restivus.addRoute('articles/:id', {authRequired: true}, {
      post: {
        roleRequired: ['author', 'admin'],
        action: function () {
          var article = Articles.findOne(this.urlParams.id);
          if (article) {
            return {status: "success", data: article};
          }
          return {
            statusCode: 400,
            body: {status: "fail", message: "Unable to add article"}
          };
        }
      }
    });
  });
}

quiconque trébuchant sur ce maintenant (2013+), consultez le Routeur météore paquet intelligent, qui fournit des méthodes pour routage côté serveur utile pour créer des interfaces RESTful.

Meteor.Router.add('/404', [404, "There's nothing here!"]);

pour vous aider dans vos recherches futures, n'oubliez pas de jeter un coup d'oeil à https://atmosphere.meteor.com - un référentiel de paquets intelligent. Et météorite est un outil CLI assez pratique pour de la version et de la gestion des paquets.

la solution la plus élégante semble être HTTP.publier . Plutôt que d'inventer une nouvelle API comme les autres, il ajoute simplement le protocole HTTP à L'interface Meteor existante publish . Cela signifie, par exemple, que Meteor.allow et Meteor.deny fonctionnent automatiquement pour HTTP aussi bien que pour DDP.

exemple:

si remis une collection et une fonction de publication Le HTTP.publish montera sur les URLs et méthodes suivantes:

GET /api/liste - toutes les données publiées

POST - /api/liste - insérer un document dans la collection

GET /api/liste/:id - trouver un document publié

METTEZ - /api/liste/:id - mise à jour d'un document

SUPPRIMER - /api/liste/:id - supprimer un document

myCollection = new Meteor.Collection('list');

// Add access points for `GET`, `POST`, `PUT`, `DELETE`
HTTP.publish(myCollection, function(data) {
  // this.userId, this.query, this.params
  return myCollection.find({});
});

It est-ce que ne gère pas encore complètement l'authentification .

Oui, vous pouvez exposer les points de repos avec Meteor en utilisant L'API privée. La fonctionnalité va devenir public prochainement, mais en attendant, consultez la section puis-je monter un autre gestionnaire d'itinéraire à travers ____meteor_bootstrap____.app? .

je sais que c'est un vieux sujet, mais au lieu d'utiliser n'importe quel paquet externe, vous pouvez utiliser le paquet Meteor WebApp: https://docs.meteor.com/packages/webapp.html .

Espère que cela aide!

je pensais mettre à jour la conversation pour 2014. Je n'ai toujours pas trouvé le moyen parfait pour mettre en place des services de repos à Meteor et j'espère que quelqu'un peut me diriger dans une autre direction pour enquêter. J'ai testé 3 projets et chacun a ses inconvénients:

meteor-routeur J'ai travaillé avec meteor-router mais la page github dit qu'il ne sera corriger les bogues aller de l'avant et d'utiliser Iron Router sur tous les nouveaux projet. J'envisage toujours d'utiliser ceci car si cela fonctionne pour moi comme-est alors les mises à niveau ne sont pas nécessaires sauf pour un certain type d'authentification.

Iron-router J'ai un exemple simple de service construit en utilisant Iron Router, mais il semble prendre en charge les services de repos encore moins que meteor-router et provoque le plantage du serveur si quelqu'un poste un JSON invalide à rest endpoint.

meteor-collectionapi Expose une api REST pour les opérations CRUD basiques sont supportées mais elle ne semble pas supporter les requêtes autres que par id.