Rest como arquitectura global de Internet usando Ruby on Rails

1. Desplegando Arquitecturas
Rest con RoR
Juan Quemada
jquemada@dit.upm.es
Joaquín Salvachúa
Jsalvachua@dit.upm.es

2. Índice
REST o WS
Principios de REST
Direccionabilidad

Interfaz uniforme

Sin estado

Representación

abierta
Conectado

Conclusiones

3. Web humana y Web programable
Web humana
Visor Web, HTTP y HTML

 HTML: presentaciones legibles
A evolucionado hacia XHTML, CCS, XML, …

Web programable
API, HTTP/SOAP, XML y ………

 XML: Datos estructurados
 Fuerte debate entre REST y “Big” Web Services
REST es
Una Web de datos accesible desde la Web humana


5. Servicios o Recursos
“Big” Web Services (W3C)
SOA: Arquitectura orientada a servicios

 APIs de Servicio de acceso a objetos remotos
RESTful Web Services
ROA: Arquitectura Orientada a Recursos

 Interfaces Uniformes (métodos HTTP)
APIs de acceso y gestión de recursos Web

 Los recursos se representan en XML, XHTML, JSON, ..

6. Que es REST
REpresentational StateTransfer.
Arquitectura de aplicaciones Web
Propuesta por Roy Fielding en su tesis doctoral (2000)

 http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm
Co-diseñador de HTTP y uno de los principales

desarrolladores del proyecto Apache
Arquitectura desacoplada y escalable

7. Rest y HTTP
REST es una abstracción que puede
implementarse sobre cualquier protocolo.
La mejor forma de implementarlo es sobre
HTTP.
Perfectamente adaptado a HTTP
Principal diferencia con SOAP


8. Principios sobre REST
Recursos Identificables (Addressability)
Interfaz de acceso uniforme
Comunicación sin estado (Statelessness)
Representación de los recursos
Hypermedia (Connectedness)

9. Identificador de recursos
Recurso: cualquier cosa en Internet que “merezca
la pena ser referenciada pos si misma”
Un fichero, un mapa, un usuario, un libro, un coche, …

Cada recurso se identifica con un URI
El URI (Permalink) da acceso al recurso

Cada URI añade valor a la red.

10. Ejemplo: Amazon S3
Servicio de almacenamiento de objetos.
Tiene 3 tipos de recursos:
1. Bucket-list: conjunto de buckets de un usuario
https://s3.amazonaws.com/
2. Bucket en particular: repositorio de objetos
https://s3.amazonaws.com/{Bucket}/
3. Objeto: posee metadato y valor
https://s3.amazonaws.com/{Bucket}/{Objeto}

11. Interfaz uniforme
Gestionar recursos solo con métodos HTTP:
GET (leer, copia solo lectura)

HEAD (cabecera)

PUT (crear)

POST (añadir)

DELETE (eliminar)

Posibilidad de hacer uso extensivo de
Cabeceras y códigos de respuesta de HTTP

Posibilidad de optimizar mediante el uso de
caches.

12. Amazon S3: Interfaz Uniforme
GET HEAD PUT DELETE
Bucket- Lista los
list buckets
de un
usuario
Bucket Lista los Crear Borrar
objetos bucket bucket
del
bucket
Objeto Obtener Obtener Crear y/o Borrar
valor y metadat Asignar Objeto

13. Representación de los recursos
Que es lo que obtenemos al acceder al URI del
recurso?
Una representación “bien conocida” y “abierta”

Pueden utilizar varios formatos:
HTML, XHTML, XML, JSON, PDF, FLASH, FLEX, ...

HTTP nos facilita el tipo (MiME) y permite
negociar el formato.
Habitualmente es XML.


14. Comunicación sin estado
El servidor NO mantiene el estado de la
conversación con cada cliente.
El estado esta explicito en las llamadas.
Cada estado se representa con una URI

Incrementa exponencialmente la escalabilidad.
Enfoque dispara y olvida (“fire and forget”).
Muy bajo acoplamiento

15. Ejemplos
Ejemplo stateful:
FTP

 Existe un directorio implicito de trabajo
HTTP stateful

 URI relativo: dependencia entre accesos consecutivos
Ejemplo statelessness:
HTTP con URLs absolutas

ATOM-PP y ATOM

Google Maps, Amazon S3, del.icio.us, …


16. Hypermedia
Las transiciones entre estados
Son siempre a través de enlaces

 No hay que acordarse de los comandos de memoria
Usar un servicio:
similar a navegar por la Web

El servidor contiene la definición del servicio
Proporciona los enlaces como parte del recurso

El cliente es genérico

Modelo distribuido de fácil evolución.

17. REST conecta la Web humana y la
Web programable
Un servicio REST bien diseñado
También puede ser utilizado con un visor Web

 Los recursos se presentan en el visor
Con CSS, XSLT, …..

 Se usa navegando
haciendo click sobre las operaciones (enlaces)

Existe un problema con XHTML4
Los formularios solo soportan GET, POST

Quiza se solucione en XHTML5


18. REST y AJAX
El despliegue AJAX de un servicio REST
Son clientes en Javascript

 que invocan el servicio con el interfaz uniforme

19. Diseño de una aplicación REST
1. Figure Out the Data Set
2. Resource Design:
Split the data set into resources

For each kind of resource

3. Name the resources with URIs
4. Expose a subset of the uniform interface
5. Design the representation(s) accepted from the client
6. Design the representation(s) served to the client
7. Connect Resources to Each Other
Integrate this resource into existing resources, using hypermedia links

and forms
8. Consider the typical course of events:
What’s Supposed to Happen?

9. Consider error conditions:
What Might Go Wrong?


20. Ventajas de RESTfull HTTP
Soporte universal y simple desde cualquier
lenguaje y plataforma.
Escalabilidad demostrada.
Soporte para redirección, cache, diferentes
representaciones.
Integración real para comunicación B2B.
Funciona con XML, pero también con otros
formatos (XHTM, JSON, ..).

21. Conclusiones
ROA: Resource Oriented Architecture
REST es el protocolo para la arquitectura del

mayor sistema distribuido del mundo (la web).
Mayor adopción
Adoptado casi unánimemente en el Web2.0

 Google, del.icio.us, Amazon, Yahoo, ….
Las normas de “Big” Web Services están

todavía incompletas
 RoR a discontinuado el soporte a “Big WS”

22. REST & RAILS

23. Controladores
Estamos habituados a:
/:controller/:action/:id

Que suele ser:
http://users/show/1

Te muestra el usuario con clave I
Tambien: /users/edit/1, /users/list/

24. Rest es sobre nombres
Nombres
Verbos Tipos

25. Nombres
Todo tiene un URI (URL) único y
permanente.
Representación del objeto en la red.

26. Verbos
Acciones a realizar sobre los recursos
“métodos” de OOP.



27. Tipos de presentación
Presentación en diversos formato
POX

Json

HTML

JPG

Uso de accept text/xml en vez de accept */*


28. No existe WSDL
Mayor flexibilidad.
Limite del modelo Stub-Skeleton.
En cada momento la serialización es “la
adecuada”.

29. Necesidad de refactorizar
Nuestro diseño

31. Equivalente a OOP
Inicialmente programas procedural.
Componerlos con entidades que hacen
operaciones (métodos).
REST es equivalente.

32. Un espacio global de aplicaciones

33. Usuarios y serviciosconsumen y manipulan la información

34. Cada Objeto es direccionable

35. Cada objeto tiene un interfaz separado de la
implementación

36. El estado se intercambia de forma explicita autodescrita

37. El significado está en las relaciones

38. El contenido y las relaciones pueden cambiar

39. Pero la identidad de la información permanece estable

40. Estado en un cierto
momento
Objecto

41. Representación
(en un cierto momento)
Recurso

42. Se basa en CRUD
Create, Read, Update, Delete
Generación automática del andamiaje.
Esto quiere decir, habitualmente:
create, show, edit, destroy


43. Diferencias
Verbo Rest Acción Antes
GET /users/1 Mostrar GET /users/show/1
DELETE /users/1 Borrar GET /users/destroy/1
PUT /users/1 Actualizar POST /users/update/1
POST /users/1 Crear POST /users/create

44. Existe otra parte
Hay que tener cuidado de no crear
Recursos basados en verbos

 Reservar.
 Autorizar
 Reconfigurar.
Si no queda más remedio
mantenerlo separado.

45. En Rails
scaffold_resource script
Model

Controller

View

Route
RESTful Client:ActivereSource

46. scaffold_resource
Generación de recursos RESTful
./script/generate scaffold_resource
Genera Model, View, Controller, Routing

47. respond_to
Un mismo recurso responde con
diferentes formatos
respond_to do |format|
format.html { }
format.xml {
render :xml => @user.to_xml
}
end

48. Necesidad de autenticación
SSL no es suficiente.
Atom Publishing Protocol (Atompp)
RFC 5023

Complementario de Atom (eq. RSS)
Permite crear recurso sin saber su URL

49. ATOM
Collections: Conjuntos de Recursos que
pueden ser obtenidos parcialmente o
totalmente.
Services: Descubrimiento y descripción de
colecciones.
Modificar: Crear, editar y borrar recursos.

50. Ventajas de Rest
URLS limpios y estables.
múltiple representaciones
menos código
Controladores tipo CRUD
Diseño de aplicación más claro
Escalabilidad

51. Antiguo testamento

52. Nuevo testamento

53. SOAP
¿SOA?
Di
ROA