2010/3/12 dwayne <[email protected]> > No conocía Sinatra, se ve bueno. Debe ser mucho más rápido de rails. > No me queda claro algo... haría otra aplicación que accede a la misma base > de datos que la actual... y ¿redefino todos los modelos? > > si, justamente esa es la idea que comentaba, de no tener todo en una sola aplicacion monolitica. para el tema de los modelos, lo que podes hacer es un symlink de una aplicacion a la otra si estas en linux. si usas git, podes poner el directorio de los modelos en un submodulo o si usas subversion en un external (creo que se llamaba así, hase mucho que no uso subversion)
-- :: nelson :: [ artesano de software & software craftsman ] http://netflux.com.ar > 2010/3/12 NachoKB <[email protected]> > >> 2010/3/12 Nelson Fernandez <[email protected]> >> >> >>> 2010/3/12 dwayne <[email protected]> >>> >>> Quiero generar una API para mi aplicación y no termino de cuál es la >>>> estructura ideal. >>>> >>>> *1)* Una idea que se me ocurrió es generar un namespace "api" e ir >>>> poniendo ahí los controllers con las diferentes funcionalidades que quiera >>>> darle a la api. Generar tal vez un api_application_controller.rb y utilizar >>>> oauth, etc. >>>> >>>> *2)* Otra es hace un api_controller.rb y meter ahí lo method que sean >>>> necesarios y las restricciones via oauth o lo que sea. >>>> >>>> *3)* y finalmente la otra es no generar un controller o namespace en >>>> particular sino que ir utilizando format.xml en los methods ya existentes >>>> para responder a los llamados desde la api y sólo publicar en la API >>>> aquellos que tengan el acceso permitido via Oauth. >>>> >>>> ¿Alguien ya hizo un desarrollo de este tipo? ¿Hay una manera "oficial" >>>> de hacer esto? ¿o una "rails way"? >>>> >>>> >>> lo que yo te aconsejaría es no poner la api en la misma aplicación. >>> utilizá otro subdominio ej: api.dominio.tld y pone ahí el manejo del api >>> con sinatra por ejemplo. >>> de esa forma el dia de mañana podes tener en servidores distintos el >>> manejador de api de la aplicacion sin ningún problema, hacer upgrades o >>> deploys sin afectar al otro. >>> >>> un tema que aveces no se tiene en cuenta y a largo plazo te puede jugar >>> en contra es el tema del versionado de las llamadas api. una forma puede ser >>> hacerlo explicita, ej: >>> >>> api.dominio.tld/servicio/v1/llamada/parametros >>> >>> otros utilizan los mismos parámetros para pasar a que version del api a >>> llamar y támbien he visto algo muy prolijo (para mi gusto) que es pasar la >>> versión del api a usar en los headers del request. >>> >>> saludos >>> >>> -- >>> :: nelson :: >>> [ artesano de software & software craftsman ] >>> http://netflux.com.ar >>> >> >> Como dice Nelson, no está bueno tener la API junto a los controllers de la >> aplicación web, dado que generalmente a una API se le debe exigir una >> estabilidad mucho mayor (en el sentido de "menos cambios") que a la >> aplicación. >> >> Por este mismo motivo está bueno explicitar la versión de la API (te >> conviene desde un principio tener este mecanismo, aunque parezca medio tonto >> cuando hay una única versión). >> >> En cuanto a la manera de explicitar la versión, usar la URL (a pesar de >> que teóricamente no correspondería) tiene sus ventajas cuando estás >> debuggeando o escribiendo un cliente. >> >> Saludos, >> >> nachokb >> >> _______________________________________________ >> Ruby mailing list >> [email protected] >> http://lista.rubyargentina.com.ar/listinfo.cgi/ruby-rubyargentina.com.ar >> >> > > _______________________________________________ > Ruby mailing list > [email protected] > http://lista.rubyargentina.com.ar/listinfo.cgi/ruby-rubyargentina.com.ar > >
_______________________________________________ Ruby mailing list [email protected] http://lista.rubyargentina.com.ar/listinfo.cgi/ruby-rubyargentina.com.ar
