Rest Conf Rails

Slideshow Transcript

1. Slide 1: Desplegando Arquitecturas Rest con RoR Juan Quemada jquemada@dit.upm.es Joaquín Salvachúa Jsalvachua@dit.upm.es
2. Slide 2: Índice REST o WS Principios de REST Direccionabilidad  Interfaz uniforme  Sin estado  Representación  abierta Conectado  Conclusiones
3. Slide 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 
4. Slide 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, ..
5. Slide 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
6. Slide 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 
7. Slide 8: Principios sobre REST Recursos Identificables (Addressability) Interfaz de acceso uniforme Comunicación sin estado (Statelessness) Representación de los recursos Hypermedia (Connectedness)
8. Slide 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.
9. Slide 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}
10. Slide 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.
11. Slide 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
12. Slide 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. 
13. Slide 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
14. Slide 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, … 
15. Slide 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.
16. Slide 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 
17. Slide 18: REST y AJAX El despliegue AJAX de un servicio REST Son clientes en Javascript   que invocan el servicio con el interfaz uniforme
18. Slide 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? 
19. Slide 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, ..).
20. Slide 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”
21. Slide 22: REST & RAILS
22. Slide 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/
23. Slide 24: Rest es sobre nombres Nombres Verbos Tipos
24. Slide 25: Nombres Todo tiene un URI (URL) único y permanente. Representación del objeto en la red.
25. Slide 26: Verbos Acciones a realizar sobre los recursos “métodos” de OOP.  
26. Slide 27: Tipos de presentación Presentación en diversos formato POX  Json  HTML  JPG  Uso de accept text/xml en vez de accept */* 
27. Slide 28: No existe WSDL Mayor flexibilidad. Limite del modelo Stub-Skeleton. En cada momento la serialización es “la adecuada”.
28. Slide 29: Necesidad de refactorizar Nuestro diseño
29. Slide 31: Equivalente a OOP Inicialmente programas procedural. Componerlos con entidades que hacen operaciones (métodos). REST es equivalente.
30. Slide 32: Un espacio global de aplicaciones
31. Slide 33: Usuarios y serviciosconsumen y manipulan la información
32. Slide 34: Cada Objeto es direccionable
33. Slide 35: Cada objeto tiene un interfaz separado de la implementación
34. Slide 36: El estado se intercambia de forma explicita autodescrita
35. Slide 37: El significado está en las relaciones
36. Slide 38: El contenido y las relaciones pueden cambiar
37. Slide 39: Pero la identidad de la información permanece estable
38. Slide 40: Estado en un cierto momento Objecto
39. Slide 41: Representación (en un cierto momento) Recurso
40. Slide 42: Se basa en CRUD Create, Read, Update, Delete Generación automática del andamiaje. Esto quiere decir, habitualmente: create, show, edit, destroy 
41. Slide 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
42. Slide 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.
43. Slide 45: En Rails scaffold_resource script Model  Controller  View  Route RESTful Client:ActivereSource
44. Slide 46: scaffold_resource Generación de recursos RESTful ./script/generate scaffold_resource Genera Model, View, Controller, Routing
45. Slide 47: respond_to Un mismo recurso responde con diferentes formatos respond_to do |format| format.html { } format.xml { render :xml => @user.to_xml } end
46. Slide 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
47. Slide 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.
48. Slide 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
49. Slide 51: Antiguo testamento
50. Slide 52: Nuevo testamento
51. Slide 53: SOAP ¿SOA? Di ROA