Desarrollo de APIs RESTful

eZpit

Hola!

Tras aprender a desarrollar APPs para Android y IOS, ahora me estoy interesando en el desarrollo web. Mi objetivo es poder desarrollar un webservice y clientes nativos para dispositivos móviles y web.

He empezado con Ruby on Rails haciendo un curso, hojeando algun libro y siguiendo tutoriales por internet. Rails me pareció adecuado porque cubria tanto back como front y a priori me solucionaba todo el problema, devolviendome views para la web y Json para las APPS de Android y IOS.

Sin embargo, tras pegar un vistazo más profundo veo mucho potencial en separar completamente front y back, de modo que el proyecto quede mejor estructurado y puedo crear un cliente wapens con AngularJS/similares que utilice la misma API JSON que uso desde Android y IOS.

Llegados a este punto en que rails queda relegado al backend, también me planteo abandonar rails y probar sinatra, o algun framework de node.js o PHP que pueda cumplir mejor la función estricta de API restful.

¿Que os parece esta manera de estructurar?
¿Que lenguaje/framework escogeríais para una API rest?

Clientes: Android / IOS / Web(Angular)
Backend: ¿Rails? ¿?¿?¿?

Un saludo.

PinVa

Hombre PHP siempre va a estar ahí, pero yo creo que ya que estas sería más interesante que te miras Django (phython) o Node.js (Con sockets.io y demás).

Una pregunta hacia tu persona que yo soy desarrollador movil android y hago servicios webs, sabes bastante de android y ios tardaste mucho en aprender los dos?

Es que no se si comenzar a aprender IOS...

2 respuestas
DarkSoldier

#2 si php siempre va a estar ahí y que ahí se quede... xD

#1 Rails es una muy buena opción y en este foro hay MUY buenos raileros por lo que si te surgiera alguna duda PODRÍAMOS ayudarte (un saludo a #mv.nerd)

2 respuestas
DaRk-eXe

#1 puedes hacer todo el back y el funcionamiento de la app (mvc) con rails y luego meter angular/<js que quieras> por encima por ejemplo.

php suxs.

B

yo me he comido decenas de frameworks(backend y frontend) y ahora mismo desarrollo frontend con angular.js y backend con node.js. Tienes un framework "full stack" llamado mean.io que te agiliza bastante las tareas. Con node.js y express puedes montarte un webservice en 1 minuto.

1 respuesta
eZpit

#2 No soy ningun experto en IOS, pero me parece relativamente sencillo, aunque supongo que tener una buena base de C/C++ me ha ayudado mucho. Desde ya hace un tiempo existe gestion automática de memoria y encima tienes una muy buena herramienta para crear la interfaz (digan lo que digan de los storyboards a mi me han ido super bien). Ademas hay infinito material didactico, codigo y extensiones.

#3 No descarto rails, pero me parece un poco overkill hacer apis en rails habiendo opciones más ligeras y rápidas.

#5 Por ahi es por donde van los tiros. La verdad es que tirar de javascript por todo me llama la atención. ¿Para node.js usas express? ¿Has probado algun framework mas?

2 respuestas
B

#6 la verdad es que siempre he tirado a pelo de node.js sin frameworks, mean.io lo llevo usando solo hace un mes y me permite eliminar muchas tareas repetitivas.

ke2g

#6 yo he usado geddy (node.js) para el backend de una app que estoy creando y la verdad es que es crema. Esta más orientado hacia aplicaciones webs, pero se adapta muy muy bien a temas de apps.

Sino siempre puedes tirar de hapi.

MTX_Anubis

Si te decantas por ruby puedes tirar por goliath

https://github.com/postrank-labs/goliath

Yo le doy a rails y dado que los proyectos que hago con rails no suelen ser muy grandes, el mismo web server despacha el api y los html aunque para otro proyecto estamos planteandonos un SOA donde se separe completamente back, front y api rest, pero bueno es un tema peliagudo. En nuestro caso probablemente el api y el front tiren de rails y el back (services) los hagamos con scala + thrift.

A mí angular ni practicamente ningún framework de js me gustan, de hecho los frameworks cada vez me gustan menos xD. De los que he probado (en general, front, back, o fullstack) Rails es quizá el que más me gusta para prototipar y no comerte mucho la cabeza pero a veces sus mayores ventajas también son sus mayores problemas xD

PinVa

#3 Exacto, me has comprendido.

Nadie de django? :(

zoeshadow

Yo no te recomiendo un framework "de los grandes" si todo lo que quieres hacer es crear una API Rest, te recomendaría empezar con un microframework, al que le puedes ir añadiendo las partes que vayas necesitando.

Estos microframeworks suelen traer un Router y poco más, por lo que empiezas a ser productivo en ellos rápidamente y según vas necesitando cosas las vas agregando ( en forma de librerías desacopladas )

Frameworks que sigan esta filosofía los tienes en todos los lenguajes...

Ruby: Sinatra
Java: Spark
PHP: Silex
Python: Flask

Lo que si que no te recomiendo es que uses ningún framework que te hace servicios Rest "por arte de magia", son el demonio y encima no aprenderás mucho.

B

Puedes utilizar rails-api, que trae todo menos la parte de vistas y assets del rails de caja

Foxandxss

Yo te aconsejaría que usaras cualquier backend, el que más rabia te de.

Rails está muy bien (es lo que a mi me gusta), aunque todo depende del backend que vayas a hacer. Rails permite hacer muchos backends complejos de forma más sencilla, peor quizá para algo pequeño no merezca mucho la pena (ruby es lento y consume mucha ram).

Luego está sinatra, está express, laravel... hay muchas opciones.

Para frontend tienes Angular (que podréis deducir que es lo que me gusta), ember, backbone...

Cualquier combinación de frontend y backend es posible.

Luego para móviles con cordova puedes usar ionic, que es básicamente apps nativas para android/ios usando angular y está muy muy bien.

1
eZpit

Bueno, finalmente he optado por MEAN stack y contento de momento.

Me ha surgido una duda nueva respecto a la autentificacion en una arquitectura IOS/ANDROID - REST API. El problema es que quiero que los usuarios puedan logear con Facebook/Google/(Twitter) de un modo nativo (usando sus SDKs). Asi pues desde las APP se hace el login y la app recibe el token, que entiendo que he de mandar ese token al server, verificarlo y devolver otro token de conexion si todo va bien.

¿Alguno habeis trabajado con logins nativos en Android/IOS o bien con logins 100% en el cliente? No tengo muy claro el proceso completo ni cual es la mejor manera de hacerlo.

2 respuestas
B

#14

Tienes varias maneras de hacerlo, si vas a utilizar solo Facebook/Google/Twitter para logear sin mas y no utilizar mucho su API, con que le generes un token en el servidor a partir del OK que te de Omniauth o lo que uses para logear y mandes ese token en las cabeceras es suficiente.

Si vas a utilizar la API de las redes sociales para algo mas que para logear te convendrá guardar el token que te devuelven y utilizarlo de la misma manera en sus peticiones.

B

#14 con ios/android no pero para node.js tienes el ´modulo "passport" que te permite hacer login con la mayoria de redes sociales.

1 respuesta
eZpit

#16 Si, con passport.js el login desde la web lo tengo solucionado. El problema es que al ser a base de redirects no es exportable a apps nativas. (que es lo que me interesa)

La solución es loguear con SDKs nativos, conseguir el token de auth y luego pasar el token al servidor. De todos modos, me asombra bastante que la mayoria de material sea para hacer full stacks, y que para cosas así no haya soluciones implementadas.

JuAn4k4

Yo me plantearía también utilizar MongoDB, que no es mas que una base de datos donde almacenas "ficheros json"/"objetos json" por asi decirlo.

1 respuesta
eZpit

#18 Precisamente MongoDB es la M del MEAN stack ;)

Por cierto, he mirado un poco REDIS, ¿que opinais? De cara a una API REST, en la que para cada petición se ha de validar el token de acceso, imagino que para almacenar dichos tokens puede suponer un incremento de velocidad considerable ¿no?

2 respuestas
B

#19 redis está bien para almacenar datos temporales que necesiten alta disponibilidad y que deban tener un tiempo limitado de vida porque si no le pones expire te deja la memoria del servidor seca. Si lo quieres usar para tokens, bien, pero no vas a notar un cambio drástico en rendimiento con respecto a mongo pues mongo también cachea en memoria por defecto.

1 respuesta
eZpit

#20 Okay thx, pues nada no me lio la vida xD

1 respuesta
ninjachu

#21 desconocía tanto framework para realizar APIs. Yo he utilizado WCF para APIs Restful en .net o webservices en Java (Todo el intercambio es mediante SOAP)

1 respuesta
JuAn4k4

#22 Eso no es rest, es soap.

#19 Desconocia el nombre, siempre lo he llamado node+mongo, y que generalmente se usaba express como framework web, lo de angular imagino que sera opcional, no ? no se muy bien que pinta en un stack la verdad.

Me das envidia :S

1 respuesta
golfomad

#1 Yo he utilizado mean stack junto con yeoman para la práctica de fin de curso y estoy encantado ;)

eZpit

A modo de referencia dejo un par de paquetes MEAN y derivados

Paquetes MEAN:
Mean.io
Meanjs (el creador de mean.io que se ha desligado y ha empezado otro proyecto)
Generador para Yeoman

Y luego, hay un kit que incluye MEN (sin angular) orientado a prototipar rápido:
Hackaton-starter

#23 Yo si entiendo que se meta angular. Hay una tendencia a derivar trabajo al cliente, así que es una pieza mas.

PD: ¿Envidia de que? xD

2 respuestas
JuAn4k4

#25 De trabajar con estas cosas :\

1 respuesta
eZpit

#26 Pero si esto lo hago en mi tiempo libre wtf xD

1 respuesta
JuAn4k4

#27 Yo no tengo de eso, envidiax2

B

#25 el creador de mean.io que se ha desligado y ha empezado otro proyecto, no me he enterado de eso y no me ha gustado nada, con el proyecto tan verde y ya hay lios de forks.

Foxandxss

A ver, yo aquí angular master, y el que diga que no, le juto a gonya.

Fuera de coñas. Mean.io es mierda, como la copa de un pino. Yo he hablado con los autores una vez y se lo dije. Verdad es que han mejorado, pero aun así, meten 200 dependencias en ese boilerplate, crear unos servicios angular muy raros (como ese global ahi potente), no sé, hay muchas otras formas de hacer MEAN (mongo, express, angular, node) sin usar esa librería.

No me extraña que el autor se haya desligado, me parece horrendo.