Í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