Me gustaría saber cómo proporcionar una aplicación Ruby con una API REST. Podría codificar algo basado en la API TCPServer de Ruby, pero parece un poco bajo nivel. ¿Crees que sería una buena solución? ¿O recomiendas un mejor enfoque?¿Cómo crear una API REST para una aplicación Ruby?
Puede usar Sinatra para escribir aplicaciones web pequeñas y enfocadas y servicios REST livianos muy rápidamente.
En la sección documentation que resaltar un par de videos sobre este asunto:
Adam Wiggins y Blake Mizerany presente Sinatra y RestClient en RubyConf 2008. La charla detalla la filosofía subyacente de Sinatra y reflexiona sobre el uso de Sinatra para construir aplicaciones del mundo real.
Adam Keys y The Pragmatic Programmers han comenzado una serie de screencasts en Sinatra. Los primeros dos episodios cubren la creación de una pequeña aplicación web y la creación de un servicio REST. $ 5 por persona.
También puede utilizar rails así, pero eso es un poco exagerado ...
estoy usando Sinatra también para desarrollar soluciones REST simples.
Lo que pasa es que Sinatra es muy flexible en muchos aspectos. Puede construir su estructura de proyecto de la manera que más le guste. Usualy tenemos un lib/tmp/y public/directories y un config.ru y app.rb archivos pero como digo que puedes construir lo que quieras.
Para recordar es que Sinatra no es un MVC habitual simplemente porque de M (modelo). Para que pueda usar sinatra para aplicaciones web simples de CRUD, simplemente necesita cargar una gema.
require 'datamapper'
u otro de su elección como sqlite, sequel, ActiveRecord, ...
y listo tienes un ORM bajo su Sinatra.
En Sinatra se definen las rutas que obedecen a cuatro propuestas principales GET, PUT POST y 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 que tiene la IDEA :)
último. Aprender Sinatra no es una pérdida de tiempo por su simplicidad y porque da (me) los cimientos de lo que es la programación web. Creo que en un futuro cercano será posible "inyectar" aplicaciones Sinatra (aplicaciones en rack) en un proyecto de Rails3.
Echa un vistazo a github, allí encontrarás muchos proyectos construidos con Sinatra. Para obtener más información, consulte Sinatra :: Base.
Para las API REST simples, también consideraría trabajar directamente contra la biblioteca Rack (es decir, es posible que no necesite un marco como Sinatra). El enrutamiento, por ejemplo, puede ser bastante fácil para casos simples. He creado un pequeño ejemplo aquí: https://gist.github.com/4685445
Hay varias capas involucradas cuando se designa una API RESTful, y en cada capa hay varios enfoques válidos.
TCPServer es de hecho de muy bajo nivel, ya que tendría que implementar el protocolo HTTP usted mismo, que no es recomendable.
Un paso más sería Rack, que se encarga de todos los detalles de HTTP de bajo nivel. Esto es lo que todos los frameworks web de Ruby como Rails, Sinatra o Ramaze usan debajo del capó. También asegura que su aplicación funciona en varios servidores de aplicaciones, como Passenger, Thin o Unicorn.
Pero incluso Rack sigue siendo de bajo nivel, le da HTTP, pero los marcos de nivel superior sacan el texto estándar de la programación web típica. Para una API, puede ver un marco mínimo como Sinatra, o un marco diseñado específicamente para API como Grape o Rails::API. Estos ya asumirán una API de estilo RESTful, por lo que debería encontrarlos como un ajuste natural.
Las API RESTful típicas se caracterizan por tener recursos identificados por URLs aducibles (controladas por convenciones) y operaciones basadas en métodos HTTP (verbos) como GET, POST, PUT, DELETE y PATCH. Sin embargo, para abrazar verdaderamente el espíritu de REST tal como lo describió Roy Fielding, podría avanzar hacia una API de "hipermedia" más completa. La diferencia más visible es que las respuestas son más autónomas. Son de tipos de medios bien definidos (definidos por usted o por las especificaciones existentes) que contienen enlaces a recursos relacionados, en lugar de meramente identificadores numéricos. De forma similar, las respuestas contienen plantillas/formularios que describen las operaciones que se pueden realizar. (Hay más que eso, pero en el nivel superficial eso es lo que notará).
Esto hace que la API sea más reconocible, tanto por humanos como por máquinas, y permite una mayor libertad en la evolución de la API. Podría haber una desventaja en el rendimiento, ya que un cliente normalmente necesitaría hacer más solicitudes para lograr lo mismo, pero esto se puede evitar mediante un diseño y almacenamiento en caché bien pensado. Garner está hecho específicamente para proporcionar un fácil almacenamiento en caché del lado del servidor.
Se podría definir sus propios tipos de medios que se adapten a su aplicación, normalmente en la parte superior de JSON o XML, o usted podría mirar a las especificaciones existentes, en particular Collection+JSON, HAL y JSON-API. Parece que en este momento HAL tiene la mayor tracción, con several libraries disponible en una variedad de plataformas.
Parece que no hay mucho sucediendo alrededor de JSON-API, pero dos proyectos significativos, ActiveModel :: Serializers y Ember-data, ambos adoptan (y al mismo tiempo, desarrollan) este formato, lo que significa que podría convertirse en una opción popular en el mundo de Ruby/Rails.
Editar: errata
1 de Sinatra. –