Comment créer une API de repos pour une application Ruby?

Vous pouvez utiliser SINATRA pour écrire des applications Web minuscules et ciblées et des services de repos léger très rapidement.

dans le Documentation Section Il met en évidence quelques vidéos à ce sujet:

• Adam Wiggins and Blake Mizerany présente Sinatra et RestClient à rubyconf 2008 . La philosophie sous-jacente de la conversation Détails de Sinatra et réfléchit à l'utilisation de Sinatra pour construire des applications du monde réelles.

• Les clés Adam et les programmeurs pragmatiques ont lancé une série de Screencasts sur Sinatra. Les deux premiers épisodes couvrent la création d'une infime application Web et de créer un service de repos. 5 $ un pop.

  Vous pouvez également utiliser rails également, mais c'est un peu de surenche ...

J'utilise Sinatra aussi pour développer des solutions de repos simples.

La chose est Sinatra est tellement flexible à bien des égards. Vous pouvez créer votre structure de projet comme vous l'aimez. Usualy nous avons un lib / tmp / et des annuaires / répertoires publics et de fichiers config.ru et app.rb, mais comme je dis que vous pouvez construire ce que vous voulez. P>

N'oubliez pas que SINATRA n'est pas un MVC habituel juste parce que de m (modèle). Pour que vous utilisiez Sinatra pour des applications Web de Crud simples, vous devez simplement charger un joyau. P>

nécessite "Datamapper" code> p>

ou autre de votre choix comme SQLite, Suite, Activerecord, ... Code> P>

Et Voilà ¡Vous avez un or, vous avez un or, sous votre sinatra. P>

Sous Sinatra, vous définissez des itinéraires qui obéissent à quatre Propose Get, Mettez post et supprimer. P>

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

Pour les API de repos simples, j'envisagerais également de travailler directement contre la bibliothèque de rack (c'est-à-dire que vous n'avez peut-être pas besoin d'un cadre comme Sinatra). Le routage par exemple peut être assez facile pour les cas simples. J'ai mis ensemble un petit exemple ici: https://gist.github.com/4685445

Il y a plusieurs couches impliquées lorsque desiging une API RESTful, et à chaque couche il y a plusieurs approches valables.

TCPServer est en effet très bas niveau, étant donné que vous devez mettre en œuvre le protocole HTTP vous-même, qui n'est pas recommandé.

Un cran serait Rack, qui prend soin de tous les détails HTTP de bas niveau. C'est ce que tous les cadres web Ruby comme Rails, Sinatra ou utilisation Ramaze sous le capot. Il a également assure que votre application fonctionne sur différents serveurs d'applications, comme passager, mince ou licorne.

Mais même rack est encore faible, il vous donne HTTP, mais les cadres de niveau supérieur prennent le passe-partout 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 comme Raisin ou Rails :: API . Ceux-ci assumeront déjà une API RESTful de style, vous devriez donc les trouver à un ajustement naturel.

API RESTful typiques sont caractérisées par des ressources identifiées par devinables (convention) URL conduite et les opérations sur celles qui sont fondées sur les méthodes HTTP (verbes) comme GET, POST, PUT, et SUPPRIMER PATCH. Pour vraiment embrasser l'esprit de repos, comme il a été décrit par Roy Fielding cependant, vous pouvez déplacer vers une API plus complète « hypermédia ». La différence la plus visible est que les réponses sont plus autonomes. Ils sont des types de supports bien définis (définis par vous-même ou par les spécifications existantes) contenant des liens vers des ressources connexes, plutôt que de simplement ids 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 à lui, mais au niveau de la surface qui est ce que vous remarquerez.)

Cela rend l'API plus découvrable, à la fois par les humains et les machines, et il permet une liberté plus grande dans l'évolution de l'API. Il pourrait y avoir un inconvénient de la performance, car un client aurait généralement besoin de faire plus de demandes pour parvenir à la même chose, mais cela peut être évité par design bien pensé et la mise en cache. Garner est spécifiquement fait pour fournir la mise en cache côté serveur facile.

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 à l'heure actuelle HAL a la plus grande traction, avec plusieurs bibliothèques disponibles sur une variété de plates-formes.

Il n'y a apparemment pas beaucoup qui se passe autour JSON-API, mais deux projets de signifacnt, ActiveModel :: Sérialiseurs et Ember-données, sont à la fois adopter (et en même temps, en développement) ce format, ce qui signifie qu'il pourrait devenir un choix populaire dans le monde Ruby / Rails.

Modifier : erreur typographique