Rest Conf Rails

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

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

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 

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

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

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 objetos https://s3.amazonaws.com/{Bucket}/ 3. Objeto: posee metadato y valor https://s3.amazonaws.com/{Bucket}/{Objeto}

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.

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

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. 

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

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

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 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? 

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 I Tambien: /users/edit/1, /users/list/

Rest es sobre nombres Nombres Verbos Tipos

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 signiﬁcado 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 representaciones menos código Controladores tipo CRUD Diseño de aplicación más claro Escalabilidad

Antiguo testamento

Nuevo testamento

SOAP ¿SOA? Di ROA

http://jsalvachua.blogspot.com	43
http://www.slideshare.net	10

Rest Conf Rails

by Joaquin Salvachua on Nov 27, 2007

Accessibility

Categories

Tags

Upload Details

Usage Rights

2 Embeds 53

Statistics

Rest Conf Rails — Presentation Transcript