Je voudrais savoir comment fournir une application Ruby avec une API REST. Je pourrais coder quelque chose basé sur l'API TCPServer de Ruby, mais cela semble un peu bas niveau. Pensez-vous que ce serait une bonne solution? Ou recommandez-vous une meilleure approche?Comment créer une API REST pour une application Ruby?
Vous pouvez utiliser Sinatra pour écrire de très petites applications Web ciblées et des services REST légers très rapidement.
Dans la section documentation ils mettent en lumière quelques vidéos sur cette question:
Adam Wiggins et Blake Mizerany présent Sinatra et RestClient à RubyConf 2008. La conférence détaille la philosophie sous-jacente de Sinatra et réfléchit à l'utilisation de Sinatra pour créer des applications dans le monde réel. Adam Keys et The Pragmatic Programmers ont lancé une série de screencasts sur Sinatra. Les deux premiers épisodes couvrent la création d'une petite application web et la création d'un service REST. 5 $ par personne
Vous pouvez également utiliser rails aussi bien, mais c'est un peu exagéré ...
J'utilise Sinatra aussi pour développer des solutions simples REST.
La chose est Sinatra est si flexible à bien des égards. Vous pouvez construire votre structure de projet comme vous le souhaitez. Habituellement, nous avons un répertoire lib/tmp/et public/et un fichier config.ru et app.rb mais comme je le disais vous pouvez construire ce que vous voulez. Pour rappel, Sinatra n'est pas un MVC habituel juste parce que de M (modèle). Pour que vous puissiez utiliser sinatra pour les applications Web Simple CRUD, vous devez simplement charger une gemme.
require 'datamapper'
ou un autre de votre choix comme sqlite, sequel, ActiveRecord, ...
et voilá vous avez un ORM sous votre Sinatra.
Sous Sinatra vous définissez les routes qui obéissent à quatre principaux propose GET, PUT POST et DELETE.
require 'rubygems'
require 'sinatra'
get '/' do
erb :home
end
get '/API/*' do
api = params[:splat]
@command_test = api[0]
@command_helo = api[1]
#...
def do_things(with_it)
#...
end
#...
end
__END__
@@home
helo
bien vous avez obtenu le ideia :)
Enfin. Apprendre Sinatra n'est pas une perte de temps à cause de sa simplicité et parce qu'il me donne les bases de ce qu'est la programmation web. Je pense que dans un proche avenir, il sera possible d '"injecter" des applications Sinatra (Rack Apps) dans un projet Rails3.
Jetez un coup d'œil sur github, vous y trouverez beaucoup de projets réalisés avec Sinatra. Pour plus d'informations, veuillez contacter Sinatra :: Base.
Pour les API REST simples, je voudrais également envisager de travailler directement sur la bibliothèque Rack (c'est-à-dire que vous n'avez pas besoin d'un framework comme Sinatra). Routage par exemple peut être assez facile pour les cas simples. J'ai mis un petit exemple ici: https://gist.github.com/4685445
Plusieurs couches sont impliquées lors de la définition d'une API RESTful, et il existe plusieurs approches valables pour chaque couche.TCPServer est en effet de très bas niveau, puisque vous devrez implémenter vous-même le protocole HTTP, ce qui n'est pas recommandé.
Rack, qui prend en charge tous les détails HTTP de bas niveau, pourrait être amélioré. C'est ce que tous les frameworks web Ruby comme Rails, Sinatra ou Ramaze utilisent sous le capot. Il assure également que votre application fonctionne sur différents serveurs d'applications, tels que Passenger, Thin ou Unicorn.
Mais même Rack est encore bas niveau, il vous donne du HTTP, mais les frameworks de plus haut niveau sortent de la programmation web typique. Pour une API, vous pouvez regarder un cadre minimal comme Sinatra, ou un cadre spécialement conçu pour les API telles que Grape ou Rails::API. Ceux-ci supposeront déjà une API de style RESTful, donc vous devriez les trouver pour être un ajustement naturel.
Les API RESTful typiques sont caractérisées par des ressources identifiées par des URL supposées (conventionnelles) et des opérations basées sur des méthodes HTTP (verbes) telles que GET, POST, PUT, DELETE et PATCH. Pour vraiment embrasser l'esprit de REST tel qu'il a été décrit par Roy Fielding, vous pouvez vous diriger vers une API "Hypermedia" plus complète. La différence la plus visible est que les réponses sont plus autonomes. Ils sont de types média bien définis (définis par vous-même ou par des spécifications existantes) contenant des liens vers des ressources connexes, plutôt que simplement des identifiants numériques. De même, les réponses contiennent des modèles/formulaires décrivant les opérations qui peuvent être effectuées. (Il y a plus, mais sur le niveau de surface c'est ce que vous remarquerez.)
Cela rend l'API plus facile à découvrir, à la fois par les humains et les machines, et permet une plus grande liberté dans l'évolution de l'API. Il pourrait y avoir un inconvénient de performance, car un client devrait généralement faire plus de demandes pour obtenir la même chose, mais cela peut être évité par une conception et une mise en cache bien pensées. Garner est spécifiquement conçu pour faciliter la mise en cache côté serveur.
Vous pouvez définir vos propres types de médias qui conviennent à votre demande, souvent au-dessus de JSON ou XML, ou vous pouvez regarder les spécifications existantes, notamment Collection+JSON, HAL et JSON-API. Il semble que HAL ait la plus grande traction actuellement, avec several libraries disponible sur une variété de plates-formes. Il semble que rien ne se passe autour de JSON-API, mais deux projets signifacnt, ActiveModel :: Serializers et Ember-data, adoptent (et développent en même temps) ce format, ce qui signifie devenir un choix populaire dans le monde Ruby/Rails.
Modifier: faute de frappe
+1 pour Sinatra. –