Principales aportes de la carrera de William Edwards Deming
10-Unidad 3: Diseños de Vista-3.2 Usos Web Services
1. Unidad 3: Webservices
3.2. Uso de Webservices
(Introducción, Características
Plataformas de Desarrollo 2
Modalidad de estudios: Presencial
Mg. Luis Fernando Aguas Bucheli
+593 984015184
@Aguaszoft
Laguas@uisrael.edu.ec
Lfabsoft2019@gmail.com
2. Objetivos del encuentro:
1. Adquirir los conceptos básicos relacionados con los
webservices
2. Reconocer las características de los webservices
Semana Nro. 10
4. 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.
6. 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.
7. 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.
8. 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.
9. 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
10. 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
12. Arquitectura REST
REST NO ES …
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.
13. 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. Arquitectura REST | 13
14. Arquitectura REST
DESCRIPCIÓN GENERAL
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
16. 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.
18. Arquitectura REST
RESTRICCIONES: UNIFORM INTERFACE
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)
19. 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.
20. 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
23. 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
24. Arquitectura REST
LEVEL 1: RESOURCES
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.
27. 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
29. Arquitectura REST
LEVEL 3: HYPERMEDIA CONTROLS
HATEOS (Hypermedia as the Engine of Application
State)
API debe poder ser navegable sin documentación
33. 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
34. 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
35. 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.