Comment exposer un service Web RESTful à l'aide de Meteor
Comment allez-vous créer un service Web reposant en utilisant Meteor. Je voudrais créer des applications dans Appcelerator qui se connectent au même backend.
Meteor peut-il résoudre ce problème?
Je suppose que vous pourriez probablement créer un service RESTful en utilisant Meteor, mais ce n'est pas vraiment ce à quoi le cadre est destiné - l'un des principaux avantages de Meteor est une interaction étroite entre le client et le serveur, et un service Web n'a pas de côté client. Je recommanderais d'envisager d'écrire un back-end de service Web dans node.js seul ou quelque chose comme https://github.com/intridea/grape si vous aimez Ruby.
J'ai fait un article complet à ce sujet dans Meteorpedia:
http://www.meteorpedia.com/read/REST_API
La publication passe en revue les 6 options pour créer des interfaces REST, du plus haut niveau (par exemple, des packages intelligents qui gèrent tout pour vous) au niveau le plus bas (par exemple, en écrivant votre propre connectHandler).
De plus, le post couvre l'utilisation d'une interface REST est la bonne ou la mauvaise chose à faire dans Meteor, fait référence à Meteor REST outils de test et explique les pièges courants comme CORS les problèmes de sécurité.
J'ai à l'origine répondu à cette question ici , mais pour récapituler:
Pour ajouter des méthodes RESTful au-dessus de vos données, consultez l'API de collecte écrite pour Meteor:
https://github.com/crazytoad/meteor-collectionapi
Quant à l'authentification pour accéder à la base de données, jetez un œil à ce projet:
https://github.com/meteor/meteor/wiki/Getting-started-with-Auth
Les deux sont définitivement infantiles en développement, mais vous pouvez créer une API RESTful et l'intégrer assez facilement à un client natif mobile.
Je sais que c'est un vieux fil, mais au cas où quelqu'un tomberait dessus, j'ai publié un paquet pour écrire REST dans Meteor 0.9.0+:
https://github.com/kahmali/meteor-restivus
Il a été inspiré par RestStop2 et construit avec le routage côté serveur de Iron Router . À mon avis pas si humble, c'est une meilleure solution que tout ce qui est affiché ici jusqu'à présent.
MISE À JOUR: Pour clarifier pourquoi [~ # ~] i [~ # ~] pense que c'est une "meilleure" solution que ceux mentionnés, je vais juste souligner les différences entre chacun:
CollectionAPI:
CollectionAPI se limite à exposer des opérations CRUD très basiques sur vos collections. Pour mon utilisation, qui consomme l'API REST dans les applications mobiles, il peut être extrêmement inutile de transmettre des documents entiers, et la plupart du temps, je dois effectuer un traitement supplémentaire des données (pour exemple, l'envoi d'un message Google Cloud dans un point de terminaison REST pour l'ajout d'un ami, mais uniquement si l'ami a été ajouté avec succès). CollectionAPI vous donne un hook qui s'exécute avant l'exécution du point de terminaison, mais ce que je comprends, il n'y a rien juste avant la réponse, vous n'avez donc 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 à chaque demande. Cela agit plus comme une clé api traditionnelle , car il semble être codé en dur dans votre application, et serait donc le même pour chaque utilisateur.
Restivus, puisqu'il ne se limite pas au travail automatisé sur les collections, vous donne un contrôle complet sur vos points de terminaison. Il fournit désormais toutes les fonctionnalités incluses dans Collection API. Il prend également en charge l'authentification des utilisateurs et les autorisations de rôle, afin que vous puissiez identifier l'utilisateur effectuant la demande (et accéder facilement à cet utilisateur à partir de points de terminaison authentifiés). Il fournit également un point de terminaison de connexion et de déconnexion pour vous aider. Je fournirai un exemple de code pour Restivus à la fin.
HTTP.publish:
D'après ce que je comprends, cela est similaire à CollectionAPI en ce qu'il se limite à exposer les opérations CRUD de base sur les collections. Celui-ci est plus spécifiquement lié à la publication de Meteor et vous permet d'utiliser une fonction de publication pour gérer les demandes GET. Je suis confus par la documentation, mais il peut ou non avoir une authentification de base disponible. Je ne l'ai pas utilisé auparavant, mais je ne suis pas un grand fan de l'API pour cela, ce qui semble un peu maladroit. Une fois que je publierai plus largement, j'essaierai de le revisiter. La même équipe a un autre package appelé HTTP.methods qui ne vous donne pas accès aux fonctions de publication, mais a une API similaire à Restivus et, à l'époque, des fonctionnalités similaires.
Restivus est "meilleur" car il ne vous limite pas à utiliser vos fonctions de publication, et permet donc un contrôle beaucoup plus fin sur vos points de terminaison. Si vous cherchez simplement à exposer vos fonctions de publication à une API externe, je vous recommande de vous en tenir à HTTP.publish. Restivus possède également une API plus simple et prend en charge la méthode HTTP PATCH (dont aucun autre package ne semble reconnaître l'existence). Leur package HTTP.methods est assez similaire à Restivus, sauf qu'il ne prend pas en charge PATCH, et bien qu'il offre une authentification de base, je pense que vous avez uniquement la possibilité de rendre tous les points finaux authentifiés, ou aucun. Restivus vous permettra de contrôler cela au niveau par point d'extrémité (et pas seulement par route). Les autorisations de rôle (par exemple, utilisateur, administrateur) sur les points de terminaison sont également disponibles sur Restivus, mais je ne vois rien à ce sujet pour HTTP.methods.
Routeur Meteor:
Ceci est déconseillé en faveur de Iron Router, voir ci-dessous.
Iron Router:
Iron Router est génial, mais il n'est pas spécialement conçu pour construire des API REST. Récemment, ils ont ajouté des fonctions correspondant aux méthodes HTTP (GET, POST, etc.), mais elles ne prend en charge aucune forme d'authentification, et tout ce à quoi vous avez accès est les objets de demande et de réponse de niveau inférieur Node, vous serez donc obligé d'apprendre à travailler avec ceux-ci. vous faites, vous constaterez qu'il y a un travail répétitif à faire dans chaque point de terminaison, comme la création de réponses avec les en-têtes et les codes de réponse appropriés. Vous devrez également vous soucier de la conformité CORS si votre API est consommée à partir du navigateur .
Restivus est en fait construit sur Iron Router et fournit une couche d'authentification sur les points de terminaison. Il supprime également la nécessité d'une interaction directe avec les objets de demande et de réponse Node, bien qu'ils soient toujours là au cas où nous aurions oublié quelque chose. Il utilise donc toute la génialité d'Iron Router avec une API de niveau supérieur pour votre plaisir de codage. Restivus est idéal 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éconseillé en faveur d'Iron Router. Ils avaient une documentation solide et une API que je préférais aux autres. Selon leur suggestion, j'ai construit un nouveau package sur Iron Router, qui est très inspiré de RestStop2. Restivus est maintenant approuvé sur la page RestStop2 GitHub, donc je pense qu'ils conviennent que c'est un remplacement digne.
Voici un petit extrait de code de la section Démarrage rapide des documents Restivus:
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 tombe sur cela maintenant (2013+), consultez le package intelligent Meteor Router , qui fournit des méthodes pour routage côté serveur utiles pour créer des interfaces RESTful.
Meteor.Router.add('/404', [404, "There's nothing here!"]);
Pour vous aider dans vos recherches futures, assurez-vous de consulter https://atmosphere.meteor.com - un référentiel de packages intelligent. Et Meteorite est un outil CLI assez pratique pour la gestion des versions et des packages.
La solution la plus élégante semble être HTTP.publish . Plutôt que d'inventer une nouvelle API comme les autres, il ajoute simplement le protocole HTTP à l'interface Meteor publish existante. Cela signifie, par exemple, que Meteor.allow et Meteor.deny fonctionne automatiquement pour HTTP ainsi que DDP.
Exemple:
Si vous remettez une collection et une fonction de publication, le
HTTP.publishse montera sur les URL et méthodes suivantes:GET -/api/list - toutes les données publiées
POST -/api/list - insérer un document dans la collection
GET -/api/list /: id - recherche un document publié
PUT -/api/list /: id - met à jour un document
SUPPRIMER -/api/list /: 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({});
});
Oui, vous pouvez exposer REST points de terminaison avec Meteor en utilisant l'API privée. La fonctionnalité deviendra publique bientôt, mais en attendant, voir Puis-je monter un autre gestionnaire d'itinéraire via ____meteor_bootstrap____.app ? .
Je sais que c'est un vieux sujet, mais au lieu d'utiliser un package externe, vous pouvez utiliser le package Meteor WebApp: https://docs.meteor.com/packages/webapp.html .
J'espère que cela aide!
Je pensais que je mettrais à jour la conversation pour 2014. Je n'ai toujours pas trouvé le moyen idéal de mettre en œuvre les services REST dans Meteor et j'espère que quelqu'un pourra m'orienter dans une autre direction pour enquêter. 'ai testé 3 projets et chacun a ses inconvénients:
meteor-router J'ai travaillé avec meteor-router mais la page github indique qu'il ne corrigera que les bugs à l'avenir et à utiliser Iron Router sur tous les nouveaux projets. J'envisage toujours de l'utiliser car si cela fonctionne pour moi tel quel, les mises à niveau ne sont pas nécessaires, à l'exception d'un certain type d'authentification.
iron-router J'ai un exemple de service simple construit en utilisant Iron Router mais il semble prendre en charge REST services encore moins que meteor-router et fait planter le serveur si quelqu'un poste json invalide pour mettre fin au point final.
meteor-collectionapi Expose un REST api pour les opérations CRUD de base sont pris en charge mais il ne le fait pas ne semblent pas prendre en charge les requêtes autrement que par id.