PDF de programación - Desarrollo REST con Rails

Desarrollo REST con Rails

Ralf Wirdemann
[email protected]

Thomas Baustert
[email protected]

traducci´on de Juan Lupion

[email protected]

17 de junio de 2007

2

ListingListado

Agradecimientos

Damos las gracias a Astrid Ritscher por las revisiones que hizo de
la primera versi´on de este documento y a Adam Groves de Berl´ın
por la revisi´on final de la versi´on en ingl´es de este documento.

Licencia

Este trabajo se distribuye bajo la licencia Creative Commons
Reconocimiento-SinObraDerivada 2.0 Espa˜na. Para ver una copia
de esta licencia visite http://creativecommons.org/licenses/by-
nd/2.0/es/ o env´ıe una carta a Creative Commons, 543 Howard
Street, 5th Floor, San Francisco, California, 94105, USA.

Ralf Wirdemann, Hamburgo en Febrero de 2007

ii

´Indice general

1. Rails y REST

1.1. ¿Qu´e es REST? . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.2. ¿Por qu´e usar REST? . . . . . . . . . . . . . . . . . . . . . . .
1.3. ¿Y qu´e hay de nuevo? . . . . . . . . . . . . . . . . . . . . . . .
1.4. Preparativos . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.4.1. Rails 1.2 . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5. Andamiaje del Recurso . . . . . . . . . . . . . . . . . . . . . . .
1.6. El modelo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.7. El controlador . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.7.1. URLs REST . . . . . . . . . . . . . . . . . . . . . . . .
1.7.2. Las acciones REST utilizan respond to . . . . . . . . . .
1.7.3. Campo Accept de la cabecera HTTP . . . . . . . . . . .
1.7.4. Especificaci´on del formato por la URL de la petici´on . .
1.8. URLs y vistas REST . . . . . . . . . . . . . . . . . . . . . . . .
1.8.1. New y Edit . . . . . . . . . . . . . . . . . . . . . . . . .
1.8.2. M´etodos de Path en los formularios: Create y Update .
1.8.3. Destroy . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.9. M´etodos de URL en el controlador . . . . . . . . . . . . . . . .
1.10. Rutas REST . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.10.1. Convenciones . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . .
1.10.2. Ajustes
. . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . .
1.11.1. Adaptaci´on de los controladores
1.11.2. Nuevos par´ametros en los helpers de path y URL . . . .
. . . . . . . . . . . . . . . .
1.11.3. Creando nuevas iteraciones
1.11.4. Edici´on de las iteraciones
. . . . . . . . . . . . . . . . .
1.12. Definici´on de otras acciones . . . . . . . . . . . . . . . . . . . .
1.12.1. ¿Seguro que no nos repetimos? . . . . . . . . . . . . . .
1.13. Definici´on de nuestros propios formatos
. . . . . . . . . . . . .
1.14. REST y AJAX . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.15. Pruebas del c´odigo . . . . . . . . . . . . . . . . . . . . . . . . .
1.16. Clientes REST: ActiveResource . . . . . . . . . . . . . . . . . .
1.17. Conclusiones
. . . . . . . . . . . . . . . . . . . . . . . . . . . .

1.11. Recursos anidados

Bibliograf´ıa

iii

1
2
3
3
4
4
4
5
6
7
8
9
10
11
13
13
14
15
16
16
17
18
20
20
23
25
26
29
29
30
31
32
34

35

iv

´INDICE GENERAL

Cap´ıtulo 1

Rails y REST

Es un hecho olvidado por muchos desarrolladores web de hoy que el proto-
colo HTTP puede hacer algo m´as que GETs y POSTs. Sin embargo, esto no
resulta tan sorprendente si consideramos que los navegadores tan s´olo sopor-
tan esas dos peticiones. GET y POST son los tipos de peticiones HTTP que se
suelen transmitir del cliente a servidor, pero el protocolo HTTP tambi´en defi-
ne los m´etodos PUT y DELETE que, en teor´ıa, se deber´ıan usar para crear o
borrar un recurso en la web. En este tutorial ampliaremos nuestros horizontes
y profundizaremos en los m´etodos PUT y DELETE.

Recientemente se ha hecho popular el t´ermino REST, que combina PUT y
DELETE junto con GET y POST. Una de las nuevas caracter´ısticas de Rails
1.2 es que soporta REST.

El tutorial comienza con una breve introducci´on de los conceptos y el
´ambito de REST. A continuaci´on se explicar´an las razones que justifican el
desarrollo de aplicaciones REST con Rails: usando andamiajes, mostraremos
el desarrollo detallado de un controlador REST nos mostrar´a las herramientas
t´ecnicas que nos ayudar´an en el desarrollo REST. Con esta base t´ecnica en
mente el siguiente cap´ıtulo mostrar´a la funcionalidad general y las modificacio-
nes en las rutas de las cuales depende en gran medida la funcionalidad REST.
El cap´ıtulo Recursos anidados presenta al lector como se pueden anidar los
recursos en una relaci´on de parentesco sin violar los conceptos de las URLs
REST. Por ultimo, el tutorial termina con cap´ıtulos sobre REST y AJAX, la
automatizaci´on de pruebas de aplicaci´on REST y una breve introducci´on a
ActiveResource, la parte de cliente de REST.

Antes de empezar, conviene aclarar que este tutorial asume que el lector
tiene al menos un conocimiento b´asico del desarrollo con Rails. Si no es este
el caso es mejor visitar alguno de los muchos tutoriales de Rails disponibles
en la Red. (e.g., [3], [4], [5]) o leer algunos de los muchos libros en la materia
que, por el momento, s´olo se encuentran en ingl´es (p.e. [1] y [2]).

1

2

CAP´ITULO 1. RAILS Y REST

1.1.

¿Qu´e es REST?

El t´ermino REST apareci´o por primera vez en la tesis doctoral de Roy
Fielding [6] y significa Representational State Transfer1. REST describe todo
un paradigma de arquitectura para aplicaciones que solicitan y manipulan
recursos en la web utilizando los m´etodos est´andar de HTTP: GET, POST,
PUT y DELETE.

En REST todo recurso es una entidad direccionable mediante una URL
´unica con la que se puede interactuar a trav´es del protocolo HTTP. Dichos
recursos pueden representarse en diversos formatos como HTML, XML o RSS,
seg´un lo solicite el cliente. Al contrario que en las aplicaciones Rails tradicio-
nales 2, la URL de un recurso no hace referencia a un modelo y su acci´on
correspondiente; tan s´olo hace referencia al propio recurso.

Figura 1.1: Recursos en la web y sus URLs

Los tres recursos de la figura 1.1 est´an representados por URLs casi id´enti-
cas seguidas por el identificador del recurso. Obs´ervese que la URL no muestra
qu´e se desea hacer con el recurso.

Un recurso, en el contexto de una aplicaci´on Rails, es una combinaci´on de
un controlador dedicado y un modelo. As´ı, desde un punto de vista t´ecnico,
los recursos proyecto de la figura 1.1 son instancias de la clase ActiveRecord
Project combinadas con un controlador ProjectsController que es reponsable
de manipular dichas instancias.

1Transferencia de estado representacional
2Cuando queramos hacer una distinci´on entre aplicaciones Rails basadas o no en REST
utilizaremos la palabra tradicional. Tradicional en este caso no quiere decir obsoleta o in-
correcta, simplemente se utiliza para hacer referencia a un concepto no de REST. De esta
manera deber´ıa ser m´as f´acil explicar esta nueva tecnolog´ıa.

Web<<Project>>Wunderloop<<Project>>Webcert<<Project>>Bellybuttonhttp://ontrack.b-simple.de/projects/1http://ontrack.b-simple/projects/2http://ontrack.b-simple.de/projects/3 1.2. ¿POR QU ´E USAR REST?

3

1.2.

¿Por qu´e usar REST?

Esta es una cuesti´on interesante, si tenemos en cuenta que se vienen desa-
rrollando con ´exito aplicaciones Rails desde hace dos a˜nos utilizando el pa-
radigma MVC. A continuaci´on mostramos una lista de caracter´ısticas de las
aplicaciones REST, que servir´a para mostrar las mejoras conceptuales que
pueden hacerse en Rails.

URLs limpias. En REST las URLs representan recursos y no acciones,
por lo tanto siempre tienen el mismo formato: primero aparece el controlador y
luego el identificador de recurso. La manipulaci´on requerida es independiente
de la URL y se expresa con la ayuda de los verbos HTTP.

Formatos de respuesta variados. Los controladores REST est´an escri-
tos de manera que las acciones pueden devolver sus resultados f´acilmente en
diferentes formatos de respuesta. Una misma acci´on puede entregar HTML,
XML, RSS o cualquier otro formato de datos seg´un los requisitos de la apli-
caci´on cliente de manera simple y sencilla.

Menos c´odigo. El desarrollar acciones ´unicas capaces de soportar m´ulti-
ples clientes distintos evita repeticiones en el sentido DRY3 y da como resul-
tado que los controladores tengan menos c´odigo.

Controladores orientados a CRUD. Los controladores y los recursos
se funden en una ´unica cosa - cada controlador tiene como responsabilidad
manipular un ´unico tipo de recurso.

Dise˜no limpio de la aplicaci´on. El desarrollo REST produce un dise˜no

de aplicaci´on conceptualmente claro y m´as f´acil de mantener.

En los pr´oximos cap´ıtulos de este tutorial veremos las caracter´ısticas an-

teriores con la ayuda de varios ejemplos.

1.3.

¿Y qu´e hay de nuevo?

Aunque podr´ıa parecer que el dise˜no de aplicaciones basado en REST hace
in´util toda la experiencia que hayamos atesorado en el desarrollo con Rails
podemos asegurar que no es el caso: REST sigue estando basado en MVC y
desde un punto de vista t´ecnico se puede resumir en las siguientes t´ecnicas
nuevas:

El uso de respond to en el c´odigo del controlador.

Nuevos m´etodos helper para enlaces y formularios.

El uso de m´etodos de URL en las redirecciones desde el controlador.

Nuevas rutas, generadas por el m´etodo resources en routes.rb.

Una vez que entendamos y comencemos a usar estas t´ecnicas el dise˜no de

aplicaciones REST se convertir´a en algo natural.

3Don’t repeat yourself

4

CAP´ITULO 1. RAILS Y REST

1.4. Preparativos

A continuaci´on explicaremos las nuevas funcionalidades espec´ıficas de REST
que incorpora Rails en el contexto de la aplicaci´on de ejemplo de nuestro libro
Rapid Web Development mit Ruby on Rails [1], Ontrack, una aplicaci´on de
gesti´on de proyectos. Por supuesto no vamos a desarrollar aqu´ı toda la aplica-
ci´on sino que utilizaremos la misma terminolog´ıa para crear