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
 

     Repre...
Web humana y Web programable
 Web humana
     Visor Web, HTTP y HTML
 

       HTML: presentaciones legibles
           ...
Servicios o Recursos
 “Big” Web Services (W3C)
      SOA: Arquitectura orientada a servicios
  

        APIs de Servici...
Que es REST
 REpresentational StateTransfer.


 Arquitectura de aplicaciones Web
     Propuesta por Roy Fielding en su tes...
Rest y HTTP
 REST es una abstracción que puede
 implementarse sobre cualquier protocolo.

 La mejor forma de implementarlo...
Principios sobre REST
 Recursos Identificables (Addressability)

 Interfaz de acceso uniforme

 Comunicación sin estado (S...
Identificador de recursos
 Recurso: cualquier cosa en Internet que “merezca
 la pena ser referenciada pos si misma”
     U...
Ejemplo: Amazon S3
Servicio de almacenamiento de objetos.

Tiene 3 tipos de recursos:

1. Bucket-list: conjunto de buckets...
Interfaz uniforme
 Gestionar recursos solo con métodos HTTP:
     GET (leer, copia solo lectura)
 

     HEAD (cabecera)
...
Amazon S3: Interfaz Uniforme
          GET         HEAD      PUT      DELETE
Bucket-   Lista los
list      buckets
       ...
Representación de los recursos
 Que es lo que obtenemos al acceder al URI del
 recurso?
     Una representación “bien cono...
Comunicación sin estado
 El servidor NO mantiene el estado de la
 conversación con cada cliente.

 El estado esta explicit...
Ejemplos
 Ejemplo stateful:
     FTP
 

       Existe un directorio implicito de trabajo
     HTTP stateful
 

       ...
Hypermedia
 Las transiciones entre estados
     Son siempre a través de enlaces
 

       No hay que acordarse de los co...
REST conecta la Web humana y la
Web programable
 Un servicio REST bien diseñado
     También puede ser utilizado con un vi...
REST y AJAX
 El despliegue AJAX de un servicio REST
     Son clientes en Javascript
 

       que invocan el servicio co...
Diseño de una aplicación REST
1.       Figure Out the Data Set
2.       Resource Design:
            Split the data set in...
Ventajas de RESTfull HTTP
 Soporte universal y simple desde cualquier
 lenguaje y plataforma.

 Escalabilidad demostrada.
...
Conclusiones
 ROA: Resource Oriented Architecture
     REST es el protocolo para la arquitectura del
 

     mayor sistem...
REST & RAILS
Controladores
  Estamos habituados a:
      /:controller/:action/:id
  


  Que suele ser:
      http://users/show/1
  
...
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
  




...
No existe WSDL
  Mayor flexibilidad.
  Limite del modelo Stub-Skeleton.

  En cada momento la serialización es “la
  adecu...
Necesidad de refactorizar
Nuestro diseño
Equivalente a OOP
  Inicialmente programas procedural.
  Componerlos con entidades que hacen
  operaciones (métodos).

  R...
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:
...
Diferencias

 Verbo     Rest       Acción             Antes

  GET     /users/1   Mostrar       GET /users/show/1

 DELETE...
Existe otra parte

    Hay que tener cuidado de no crear
        Recursos basados en verbos
    

         Reservar.
   ...
En Rails
  scaffold_resource script
      Model
  

      Controller
  

      View
  


  Route
  RESTful Client:Activ...
scaffold_resource
  Generación de recursos RESTful

  ./script/generate scaffold_resource
  Genera Model, View, Controller...
respond_to
  Un mismo recurso responde con
  diferentes formatos



     respond_to do |format|
       format.html { }
   ...
Necesidad de autenticación
  SSL no es suficiente.
  Atom Publishing Protocol (Atompp)
      RFC 5023
  


  Complementar...
ATOM
 Collections: Conjuntos de Recursos que
 pueden ser obtenidos parcialmente o
 totalmente.
 Services: Descubrimiento y...
Ventajas de Rest
  URLS limpios y estables.
  múltiple representaciones
  menos código
  Controladores tipo CRUD
  Diseño ...
Antiguo testamento
Nuevo testamento
SOAP

     ¿SOA?
Di



             ROA
Rest Conf Rails
Rest Conf Rails
Upcoming SlideShare
Loading in …5
×

Rest Conf Rails

3,927 views

Published on

Rest como arquitectura global de Internet usando Ruby on Rails

Published in: Technology
0 Comments
3 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
3,927
On SlideShare
0
From Embeds
0
Number of Embeds
46
Actions
Shares
0
Downloads
87
Comments
0
Likes
3
Embeds 0
No embeds

No notes for slide

Rest Conf Rails

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

×