Rest Conf Rails

Desplegando Arquitecturas Rest con RoR

Juan Quemadajquemada@dit.upm.es

Joaquín SalvachúaJsalvachua@dit.upm.es

Índice

REST o WSPrincipios de REST Direccionabilidad Interfaz uniforme Sin estado Representación

abierta Conectado

Conclusiones

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

Web humana y Web programable

“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, ..

Servicios o Recursos

Que es RESTREpresentational 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

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

Principios sobre REST

Recursos Identificables (Addressability)

Interfaz de acceso uniforme

Comunicación sin estado (Statelessness)

Representación de los recursos

Hypermedia (Connectedness)

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.

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 objetoshttps://s3.amazonaws.com/{Bucket}/

3. Objeto: posee metadato y valorhttps://s3.amazonaws.com/{Bucket}/{Objeto}

Interfaz uniformeGestionar 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.

Amazon S3: Interfaz UniformeGET HEAD PUT DELETE

Bucket-list

Lista los buckets de un usuario

Bucket Lista los objetos del bucket

Crear bucket

Borrar bucket

Objeto Obtener valor y metadato del objeto

Obtener metadato del objeto

Crear y/o Asignar valor a objeto y metadato

Borrar Objeto

Representación de los recursosQue 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.

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

EjemplosEjemplo 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, …

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.

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

REST y AJAX

El despliegue AJAX de un servicio REST Son clientes en Javascript

que invocan el servicio con el interfaz uniforme

Diseño de una aplicación REST1. Figure Out the Data Set 2. Resource Design:

Split the data set into resources For each kind of resource

3. Name the resources with URIs4. Expose a subset of the uniform interface5. Design the representation(s) accepted from the client6. Design the representation(s) served to the client7. 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?

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, ..).

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”

REST & RAILS

Controladores

Estamos habituados a: /:controller/:action/:id

Que suele ser: http://users/show/1

Te muestra el usuario con clave ITambien: /users/edit/1, /users/list/

Rest es sobre nombres

Nombres

TiposVerbos

Nombres

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

Verbos

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

Tipos de presentación

Presentación en diversos formato POX Json HTML JPG

Uso de accept text/xml en vez de accept */*

No existe WSDL

Mayor flexibilidad.Limite del modelo Stub-Skeleton.

En cada momento la serialización es “la adecuada”.

Necesidad de refactorizar Nuestro diseño

Equivalente a OOP

Inicialmente programas procedural.Componerlos con entidades que hacen operaciones (métodos).

REST es equivalente.

Un espacio global de aplicaciones

Usuarios y serviciosconsumen y manipulan la información

Cada Objeto es direccionable

Cada objeto tiene un interfaz separado de la implementación

El estado se intercambia de forma explicita autodescrita

El significado está en las relaciones

El contenido y las relaciones pueden cambiar

Pero la identidad de la información permanece estable

Estado en un cierto momento

Objecto

Representación (en un cierto momento)

Recurso

Se basa en CRUD

Create, Read, Update, Delete Generación automática del andamiaje. Esto quiere decir, habitualmente: create, show, edit, destroy

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

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.

En Rails

scaffold_resource script Model Controller View

Route RESTful Client:ActivereSource

scaffold_resource

Generación de recursos RESTful

./script/generate scaffold_resource Genera Model, View, Controller, Routing

respond_to

Un mismo recurso responde con diferentes formatos

respond_to do |format| format.html { } format.xml { render :xml => @user.to_xml } end

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

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.

Ventajas de Rest

URLS limpios y estables.múltiple representacionesmenos códigoControladores tipo CRUDDiseño de aplicación más claroEscalabilidad

Antiguo testamento

Nuevo testamento

¿SOA? Di

SOAP

ROA