10- Unidad 3: Webservices - 3.2 Uso de Web services (Introducción, Características)

1. Unidad 3. Webservices
3.2. Uso deWebservices
(Introducción, Características)
Autor(es):
Ciencias de la Ingeniería
Carrera de Sistemas
Plataformas de Desarrollo 2
Mg. Luis Fernando Aguas Bucheli
+593 984015184
@Aguaszoft
Laguas@uisrael.edu.ec
Aguaszoft@Outlook.es

2. “No puedes derrotar a la persona que
nunca se rinde”
(Anónimo)
Ciencias de la Ingeniería
Carrera de Sistemas
Plataformas de Desarrollo 2

3. Resultado de Aprendizaje
Desarrollar soluciones informáticas mediante metodologías,
herramientas y estándares que satisfagan los requerimientos de
las organizaciones sobre la base de los principios de la sociedad
de la información.

4. Contenidos
Introducción
Objetivos
Desarrollo de Contenidos
Conclusiones
Bibliografía

5. 3.2. Uso de Webservices

6. Objetivos
Adquirir los conceptos básicos relacionados con el web Service
Reconocer las características del diseño de web Service

7. Estado del arte de los Web Services
Comparar REST y SOAP, quizás no es lo más correcto debido a
que no son exactamente lo mismo.
Mientras que SOAP es un protocolo estándar definido para
realizar esta función, REST es un estilo arquitectónico, por lo
que no es un estándar en términos de integración e
implementación. REST utiliza varios estándares y protocolos
ya definidos para su funcionamiento.

8. Estado del arte de los Web Services

9. Rest
Aspectos positivos:
Fácil de implementar y simple de interpretar
Es más ligero, sus respuestas contienen exactamente la información que
necesitamos.
Solo se envía la representación de un recurso.
Bajo consumo de recursos Al no tener estado, facilita la sincronización de servidores y
por consiguiente facilita la escalabilidad del sistema.

10. Rest
Aspectos positivos:
Es flexible en cuanto al tipo de respuesta que se necesita, ya que puede consumir
XML o JSON Funciona muy bien con dispositivos móviles y aplicaciones RIA (Rich
Internet Application) basadas en Javascript facilitando la portabilidad a otras
tecnologías HATEOAS (Hypermedia as the Engine of Application State), posibilita el
descubrir otros recursos cuando recibamos la representación de uno de ellos.

11. Rest
Aspectos negativos:
La seguridad puede ser un problema y puede llegar a ser una tarea muy difícil
de implementar correctamente.
No hay un estándar en sus respuestas por lo que no se definen tipos de datos.
A la hora del diseño, el manejo del espacio de nombres puede ser algo más
rebuscado.

12. SOAP
Aspectos positivos:
Utilizando tecnología .NET o Java es muy sencillo de consumir y existen varias
herramientas de desarrollo para poder consumirlo.
Funciona muy bien en entornos empresariales.
Buen manejo de errores.
Estructura más rígida y fuerte.
Mayor seguridad en el transporte

13. SOAP
Aspectos negativos:
Es complejo y difícil de entender
Sólo sirve XML
No aprovecha la infraestructura web como cachés, negociación de formatos
Depende de la especificación WSDL para poder operar con los procesos

14. Flujograma conexión HTTP bajo TCP

15. Arquitectura REST | 2
Índice
Qué no es REST
Introducción
Restricciónes
Richardson Madurity Model
Rest Anti Patterns
Seguridad
Documentación
Algunos Frameworks Java y PHP
Demo Time
Q&A

16. Arquitectura REST
REST NO ES …
Arquitectura REST | 16
REST no es un tecnología.
REST no es un framework.
REST no es un patrón de diseño.
REST no es un protocolo.
REST no es un estándar.

17. Arquitectura REST
¿QUÉ ES REST?
REST is a coordinated set of architectural
constraints that attempts to minimize latency
and network communication while at the same
time maximizing the independence and scalability
of component implementations.
Roy Fielding
Tesis Doctoral
Architectural Styles and the Design of Network-
based Software Architectures, Universityof
California, Irvine, 2000
Arquitectura REST | 17

18. Arquitectura REST
DESCRIPCIÓN GENERAL
Arquitectura REST | 18
REST == REpresentational State Transfer
Basado en Recursos (Elemento de información)
Representación (Formato de la información)
Restricciones:
 Client-Server
 Stateless
 Cacheable
 Uniform Interface
 Layered System
 Code-on-demand

19. Arquitectura REST
RESTRICCIONES: CLIENT-SERVER
Separación de responsabilidades.
Mejora la portabilidad a distintas plataformas.
Aumento de la escalabilidad.
Componentes evolucionan de forma
independiente.
Arquitectura REST | 19

20. Arquitectura REST
RESTRICCIONES: STATELESS
Cada petición contiene toda la información
necesaria para que el servidor la procese.
El estado de sesión se mantiene totalmente en el
cliente.
Componentes evolucionan de forma
independiente.
Arquitectura REST | 20

21. Arquitectura REST
RESTRICCIONES: CACHEABLE
Respuestas del
son cacheables:
 Implícita
 Explicita
 Negociables
servidor (representaciones)
Arquitectura REST | 21

22. Arquitectura REST
RESTRICCIONES: UNIFORM INTERFACE
Arquitectura REST | 22
Principal característica diferenciadora frente a
otras arquitecturas.
Las implementaciones se separan de los
servicios que proporcionan
¿Cómo?
 Verbos HTTP
 URIs (nombres de recursos)
 Respuestas HTTP (status, body)

23. Arquitectura REST
RESTRICCIONES: LAYERED SYSTEM
Los servicios REST están orientados a la
escalabilidad.
El cliente no sabe si la petición se realiza
directamente a un servidor, un sistema de
cachés o por ejemplo un balanceador que se
encarga de redirigirlo hacia un servidor final.
Arquitectura REST | 23

24. Arquitectura REST
RESTRICCIONES: CODE-ON-DEMAND
s
Servidor puede extender o personalizar
temporalmente la funcionalidad del cliente.
Transferencia de la lógica al cliente.
Cliente ejecuta la lógica.
Restricción opcional
Ejemplos:
 Java Applet
 JavaScript
Arquitectura REST | 24

25. Arquitectura REST
OBJETIVOS
Simplicidad
Escalabilidad
Portabilidad
Independizar el cliente/servidor
Sintaxis “universal”
Sistemas tolerantes al cambio
Minimizar la latencia
Arquitectura REST | 25

26. RICHARDSON MATURITY MODEL
Arquitectura REST
Arquitectura REST | 26

27. Arquitectura REST
LEVEL 0: THE SWAMP OF POX (PLAIN OLD XML)
Una URI, un Método HTTP
HTTP como un sistema de transporte para
interacciones remotos
Basado en Remote Procedure Invocation.
XML-RPC y SOAP
Arquitectura REST | 27

28. Arquitectura REST
LEVEL 1: RESOURCES
Arquitectura REST | 28
URI (Uniform Resource Identifier)
Los nombres de URI no deben implicar una
acción
Evitar uso de verbos.
Deben ser Únicas
Independientes del formato.
Deben mantener una jerarquía lógica.
Los filtrados de información de un recurso no se
hacen en la URI.

29. LEVEL 1: RESOURCES
Arquitectura REST
Arquitectura REST | 29

30. LEVEL 1: RESOURCES
Arquitectura REST
Arquitectura REST | 30

31. Arquitectura REST
LEVEL 2: HTTP VERBS
GET para obtener la representacion/es de un
recurso/s
POST para crear un recurso
PUT para modificar un recurso
DELETE para eliminar un recuerso
PATCH para actualizar parcialmente un recurso
 Uso de HTTP Status Code para indicar el resultado:
 HTTP/1.1 2xx Petición Correcta
 HTTP/1.1 4xx Errores del Cliente
 HTTP/1.1 5xx Errores en el Servidor
Arquitectura REST | 31

32. LEVEL 2: HTTP VERBS
Arquitectura REST
Arquitectura REST | 32

33. Arquitectura REST
LEVEL 3: HYPERMEDIA CONTROLS
 HATEOS (Hypermedia as the Engine of Application
State)
 API debe poder ser navegable sin documentación
Arquitectura REST | 33

34. LEVEL 3: HYPERMEDIA CONTROLS
Arquitectura REST | 34
Arquitectura REST

35. LEVEL 3: HYPERMEDIA CONTROLS (EJEMPLO)
Arquitectura REST
Arquitectura REST | 35

36. LEVEL 3: HYPERMEDIA CONTROLS (EJEMPLO)
Arquitectura REST
Arquitectura REST | 36

37. Arquitectura REST
REST ANTI-PATTERS BY STEFAN TILKOV
Todas las peticiones a través de GET
Todas las peticiones mediante POST
Cache, ¿qué cache?????
No utilizar códigos de respuesta
Mal uso de cookies
Olvidarnos de Hypermedia
Haciendo caso omiso de los tipos MIME
Mal uso de las cabeceras HTTP
Arquitectura REST | 37

38. Arquitectura REST
SEGURIDAD
Recordad que nuestros servicios web deben ser
stateless (sin estado):
 No utilizar cookies o HTTP Session.
El cliente debe enviar las credenciales de
autenticación en cada llamada.
Opciones:
 HTTP Security
 OAuth
Arquitectura REST | 38

39. Arquitectura REST
DOCUMENTACIÓN
JavadocTagsForExtendedWADL
 Permite añadir más información al WADL.
Se puede aplicar un transformada para generar
documentación ad hoc.
Swagger
 Ampliamente extendido y estable.
 Independiente del lenguaje de programación.
 UI para probar los servicios.
Arquitectura REST | 39

40. ALGUNOS FRAMEWORKS JAVA Y PHP
Arquitectura REST
Arquitectura REST | 40

41. LECTURAS RECOMENDADAS
Arquitectura REST
Arquitectura REST | 41

42. Bibliografía