Comment créer une API REST à l'aide de Rails 3.0?

Question

Je n'arrive pas à trouver beaucoup d'informations sur le web sur les différentes approches pour la construction d'une API REST dans les Rails; donc j'ai un peu poser deux questions:

1. Quelqu'un peut-il m'indiquer quelques articles qui montrent les avantages/inconvénients des différentes approches?
2. Veuillez s'il vous plaît de partager vos pensées sur les avantages/inconvénients des approches suivantes?

 

Les Approches Proposées

 

1. Utiliser les contrôleurs standard de renvoyer du XML lorsqu'un utilisateur ajoute .xml à la fin de l'URL

   Pour:

   • C'est intégré dans les Rails et très facile à utiliser
   • Suit la même ressource approche fondée sur les Rails de a, de sorte qu'il sera facile pour les utilisateurs existants de comprendre/rappelez-vous

   Inconvénients:

   • L'API n'est pas clairement séparées à partir du site principal, plus difficile à maintenir
   • Les gens peuvent supposer que l'ajout d' .xml permettra de travailler dans des endroits qu'il n'a pas

2. Utilisation des espaces de routage pour créer des contrôleurs d'API qui ne traitent que des API fonctions, mais encore avoir accès aux mêmes modèles que le site utilise des

   Pour:

   • L'API est la plupart du temps séparés
   • Utilise toujours les ressources complète de contrôleurs

   Inconvénients:

   • Les URLs sont de la forme de site.com/api/resource.xml ce qui peut rendre les gens supposent tous des ressources sont disponibles
   • API est encore partie du code du site/projet; par conséquent, plus difficile à maintenir

3. Utiliser l'itinéraire de l'acheminement et des contraintes pour transférer tous les appels d'API à un Rack application

   Pour:

   • L'API est entièrement séparé
   • Pas besoin d'utiliser la Ressource-plein de style, si nous ne voulons pas
   • Url montrent clairement c'est une API et vous devriez vérifier les docs de voir ce qui est disponible (au moins, mon esprit fonctionne de cette façon; je suppose que d'autres dev esprits aussi)

   Inconvénients:

   • Plus difficile à utiliser des modèles de code de site web
   • Plus facile à maintenir car un autre projet, mais cela signifie que plus difficile à intégrer avec site existant
   • Doit garder des bases de codes de synchronisation comme les modèles peuvent changer pour le site des fonctionnalités et des corrections de bugs

Answer 1

Je propose que l'API d'être dans le même projet que votre site web n'est pas une mauvaise chose tant que le code est à SEC*. Comme vous l'avez souligné, d'avoir plusieurs bases de code est un défi parce que vous devez les garder en synchronisation avec toutes les fonctionnalités/correction que vous faites. C'est plus facile à maintenir si ils sont dans le même lieu. Tant que vous conservez votre code SEC, cette méthode est le gagnant clair.

Je voudrais proposer XML et JSON de contrôleurs avec un sous-domaine géré par les Rails du moteur de routage. Quand quelqu'un a ramassé sur le modèle de api.site.com/resource.xml et essaie d'accéder à une ressource qui n'est pas là, c'est vraiment pas une grosse affaire. Tant que votre API est clairement expliquées et vous ne/erreur gracieusement lorsqu'ils essaient d'accéder à une ressource n'est pas dans votre API, il devrait être très bien. Je voudrais essayer de retourner un message disant que la ressource n'est pas disponible, et l'url de votre documentation de l'api. Cela ne devrait pas être un problème d'exécution pour toutes les API des consommateurs, comme cela devrait être le cadre de la découverte de votre API.

Juste mon de 0,02$.

*SEC = Ne pas se Répéter. SEC code signifie que vous n'avez pas de copier-coller ou de réécrire la même chose pour votre site et votre api; extraire et d'appel à partir de plusieurs endroits.

Answer 2

Je pense que la meilleure solution pour vous est de fusionner vos deux premiers points.

Je suggère l'utilisation de JSON au lieu de XML: le seul point en faveur de XML est de XPath qui est inutile dans les données renvoyées. JSON mène à de meilleurs temps de réponse (et plus lisible des données pour une meilleure mise ! :p). De Plus, la plupart des langues peut lire JSON. Par exemple, PHP peut nativement parser JSON pour tableau/objet avec json_decode, donc c'est un bon point. ;)

Pour les contrôleurs, vous pouvez d'espace de noms, mais ce n'est pas une obligation, c'est peut-être mieux, dans certains cas, pour éviter des actions avec des tonnes de conditions. Avec les Rails de routeur 3, de la séparation des appels de l'API dans un sous-domaine (api.webapp.com) est trivial).

Pour le modèle, assurez-vous que vous utilisez la même que celle utilisée dans l'ensemble de l'application.

Les nouveaux rails routeur syntaxe est-à sucre, vous allez vous régaler. Bonne chance et amusez-vous! :)