Your SlideShare is downloading. ×
  • Like
Scom5 Ws Ii
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Now you can save presentations on your phone or tablet

Available for both IPhone and Android

Text the download link to your phone

Standard text messaging rates apply

Scom5 Ws Ii

  • 825 views
Published

 

Published in Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
825
On SlideShare
0
From Embeds
0
Number of Embeds
1

Actions

Shares
Downloads
36
Comments
0
Likes
1

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. Aplicaciones y Servicios Web II (REST) Joaqu ín Salvachúa [email_address] http://jsalvachua.blogspot.com
  • 2. Índice
    • Problema a resolver
    • Arquitectura
    • SOAP
    • WSDL
    • UDDI
    • Conclusiones
  • 3. Que es REST
    • RE presentational S tate T ransfer.
    • Arquitectura de aplicaciones Web descrita por Roy Fielding en su tesis doctoral (uno de los principales desarrolladores del proyecto Apache).
    • http://www.ics.uci.edu/~fielding/pubs/dissertation/
    • Arquitectura desacoplada y escalable para aplicaciones Web.
  • 4. Rest y HTTP
    • REST es una abstracci ón que puede implementarse sobre cualquier protocolo.
    • La mejor forma de implementarlo es sobre HTTP.
    • Encaja perfectamente con el protocol (diferencia con SOAP).
  • 5. Principios sobre REST
    • Recursos Identificables
    • Interfaz de acceso uniforme
    • Comunicaci ón sin estado
    • Representación de los recursos
    • Hypermedia.
  • 6. Identificador de recursos
    • Cada recurso representara una entidad real o virtual de la aplicaci ón ( un usuario, un libro, un coche).
    • En la Web esto ser realizará mediante el uso de URI.
    • Cada URI añade valor a la red.
  • 7. Interfaz uniforme
    • Una vez que tenemos localizado el recursos podemos interactuar con é l.
    • Uso de los verbos de las acciones de HTTP:
      • GET (copia solo lectura)
      • PUT (cambiar parte )
      • POST (añadir)
      • DELETE (eliminarlo)
    • Posibilidad de optimizar mediante el uso de caches.
  • 8. Representación de los recursos
    • Que es lo que obtenemos al acceder al URI del recurso.
    • Pueden existir varios :
      • HTML, PDF, XML.
    • HTTP nos facilita el tipo (MiME) y permite la negociaci ón de ello.
    • Habitualmente es XML.
    • Necesidad de representaciones “bien conocidas”.
  • 9. Comunicaci ón sin estado
    • El servidor NO necesita mantener el estado de la conversaci ón con cada cliente.
    • Enfoque dispara y olvida (“fire and forget”).
    • Mayor ventaja de esta arquitectura.
    • El estado esta explicito en las llamadas.
    • Incrementa exponencialmente la escalabilidad.
    • Muy bajo acoplamiento
  • 10. Hypermedia
    • Todas las transiciones de estado son mediante el uso de links.
    • Permite delegar,
    • Los enlaces deberían estar proporcionados por el servidor, no por el cliente.
    • Permite un modelo distribuido y de fácil evoluci ón.
  • 11. Diseño de una aplicación REST
    • Identificar recursos y diseñar los URI.
    • Seleccionar los formatos de comunicación.
    • Identificar la semántica de los métodos.
    • Seleccionar los códigos de respuesta/error.
  • 12. 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.
  • 13. Comunicaci ón asíncrona
    • HTTP es petici ón - respuesta.
    • Posiblidad de usar 202 Accepted como respuesta.
    • Necesidad de monitorizar o pasar un URI para ser notificado.
  • 14. Mensaje Fiable / encriptaci ón
    • Uso de HTTPS
      • Capa SSL/TLS
    • Posibilidad de usar el protocolo ATOM y ATOM-PP
    • Enfoque KISS
  • 15. Conclusiones
    • REST es la arquitectura para el mayor sistema distribuido del mundo (la web).
    • Mayor adopci ón frente a los problema de los Web Services.
  • 16. Comparaci ón con WS
    • Mejor uso del protocolo HTTP (protocolo a nivel de aplicaci ón).
    • Mayor facilidad de uso.
    • Soporte directo y transparente de las aplicaciones.
    • Complejidad de WS-*