Plataformas de
Desarrollo 2
Tema: 2 Web Services
Mg. Luis Fernando Aguas Bucheli
+593 984015184
@Aguaszoft
Laguas@uisrael.edu.ec
“La vida es mejor para aquellos que hacen lo
posible para tener lo mejor” – John Wooden.
Objetivo
• Construir aplicaciones de
software Web con acceso
a datos y que resuelva
problemas basados en
casos reales utilizando
Visual Studio
● 2.2 Rest y RestFul
Contenido
ODS
● 4.3 De aquí a 2030, asegurar
el acceso igualitario de todos
los hombres y las mujeres a
una formación técnica,
profesional y superior de
calidad, incluida la enseñanza
universitaria
META
2.2 Rest y RestFul
¿Qué es REST?
● Origen: Fielding, Roy T. “Architectural Styles
and the Design of Network-based Software
Architectures.” Tesis Doctoral, Universidad de
California, 2000.
● Describe un estilo de arquitectura que utilizar
como modelo en los servicios de computación
Web.
● Estilo de arquitectura: Conjunto coordinado de
restricciones que controlan el funcionamiento y
características de los elementos de la arquitectura
y permite las relaciones de unos con otros.
● Describe cómo debería comportarse la Web
● NO es un estándar
¿Por qué ha triunfado la Web?
● Escalabilidad en interacciones entre componentes
● Generalidad en las interfaces
● Desarrollo independiente de componentes
● Existencia de componentes intermediarios (proxys)
Principios de REST
● El estado y la funcionalidad de las aplicaciones se divide en recursos
○ REST es orientado a recursos y no a métodos
○ No se accede directamente a los recursos, sino a representaciones de los mismos
Servicio
Acceso
CUENTA
BANCARIA
=123
USUARIO
Recurso
CUENTA
BANCARIA
=123
USUARIO
Sistema basado en REST
Sistema basado en SOAP
Principios de REST II
● Todo recurso es identificado de forma única global mediante
una sintaxis universal. Como en HTTP los recursos se
identifican mediante URIs (Uniform Resource Identifier).
○ Conjunto potencialmente infinito de recursos.
● Todos los recursos comparten un interfaz uniforme formado
por:
○ Conjunto de operaciones limitado para transferencia de
estado
■ En HTTP GET, PUT, POST, DELETE
○ Conjunto limitado de tipos de contenidos
■ En HTTP se identifican mediante tipos MIME: XML , HTML...
Principios de REST III
● Un protocolo cliente/servidor, sin estado y basado en capas
● Cada mensaje contiene la información necesaria para
comprender la petición (mensajes autocontenidos, como
HTTP)
RED
ESTADO A
ESTADO B
ESTADO C
ESTADO A
ESTADO B
ESTADO C
Principios de REST IV
● Uso de hipermedios, tanto para la información de la
aplicación como para las transiciones de estado de la
aplicación.
● A través de sucesivas peticiones de recursos cambia el
estado de la aplicación.
Principios de REST V
● Promueve mecanismos caché y sistemas intermedios
Ventajas de REST
● Mejora el tiempo de respuesta gracias al
mecanismo Caché y los mensajes auto-descriptivos.
● Disminución de carga en servidor
● Mayor escalabilidad al no requerir mantenimiento de
estado en el servidor
● Facilita desarrollo de clientes (menor dependencia
del servidor).
● Mayor estabilidad frente a futuros cambios
○ Permite evolución independiente de los tipos de
documentos al procesar éstos en el cliente.
Diferencias entre REST y SOAP
SOAP REST
Orientado a RPC Orientado a recursos
Servidor almacena parte del estado El estado se mantiene sólo en el
cliente, y no se permiten las sesiones
Usa HTTP como túnel para el paso
de mensajes
Propone HTTP como nivel de
aplicación
Ejemplo
● Sistema basado en
SOAP
○ Énfasis en diversidad
de operaciones
(verbos)
getUser()
addUser()
removeUser()
updateUser()
getLocation()
addLocation()
removeLocation()
updateLocation()
 Sistema REST
 Énfasis en diversidad
de recursos (nombres)
User {} Location{}
 Registro del recurso User
(accesible con HTTP
GET):
<usuario>
<nombre>Benito Pérez</nombre>
<genero>masculino</genero>
<localizacion
href="http://www.example.org/locations/
spain/oviedo"> Oviedo,
Spain
</localizacion>
</usuario>
Soap vs REST: Críticas
● SOAP no es transparente, apuesta
por el encapsulamiento
● SOAP no dispone de un sistema de
direccionamiento global
● SOAP puede derivar en agujeros de
seguridad
● SOAP no aprovecha muchas de las
ventajas de HTTP al usarlo
solamente como túnel
● SOAP no puede hacer uso de los
mecanismos Caché
● REST es poco flexible
● REST no está preparado para
albergar Servicios Web de gran
complejidad como las aplicaciones
B2B
● REST tiene grandes problemas de
seguridad al no soportar el concepto
de sesión
Uso de REST
● Adecuado para grandes cantidades de información pública para grupos
desconocidos de usuarios
● No adecuado para sistemas complejos cerrados
Ejemplo de Implementaciones
● AMAZON
○ Pionera en el uso de REST en 2002
○ Base de datos con todos los productos que vende
○ Los productos se acceden como recursos, no como métodos de
búsqueda
○ API disponible en associates.amazon.com
○ Posible carencia, si realiza servicios más sofisticados puede que deba
migrar a SOAP
● EBAY
○ Desarrolló una API REST en 2004
○ Consulta de productos a través del método GetSearchResults()
● OTROS: YOUTUBE, YAHOO, FLICKR, etc..
Visión general conceptual
Definición de servicio web RESTful
● Un servicio web RESTful es:
○ Un conjunto de recursos web.
○ Interrelacionadas.
○ Centrado en datos, no centrado en la funcionalidad.
○ Orientado a la máquina.
○ Como las aplicaciones web, pero para máquinas.
○ Como WS-*, pero con más recursos web.
WS-* representa una variedad de especificaciones relacionadas con los servicios web
basados en SOAP.
WS-
collection
service
collection
entry
entry
entry
listEntries()
addEntry()
getEntry()
deleteEntry()
updateEntry()
listEntries()
addEntry()
getEntry()
deleteEntry()
updateEntry()
RESTful
● Un servicio SOAP (WS) tiene un único extremo que controla todas las
operaciones, por lo que tiene que tener una interfaz específica de la
aplicación.
● Un servicio RESTful tiene una serie de recursos (la colección, cada entrada),
por lo que las operaciones se pueden distribuir en los recursos y asignarse a
un pequeño conjunto uniforme de operaciones.
Futuro de REST
● SOAP mantiene el monopolio de los Servicios Web
● Carencia de documentación
● Escasas implementaciones y ejemplos prácticos para acercar
REST al programador común
● Única solución, crear organización o entidad que agrupe el
disperso y escaso trabajo que existe sobre REST
Gracias
Responsabilidad con pensamiento positivo

S4-PD2.pptx

  • 1.
    Plataformas de Desarrollo 2 Tema:2 Web Services Mg. Luis Fernando Aguas Bucheli +593 984015184 @Aguaszoft Laguas@uisrael.edu.ec
  • 2.
    “La vida esmejor para aquellos que hacen lo posible para tener lo mejor” – John Wooden.
  • 3.
    Objetivo • Construir aplicacionesde software Web con acceso a datos y que resuelva problemas basados en casos reales utilizando Visual Studio ● 2.2 Rest y RestFul Contenido
  • 4.
    ODS ● 4.3 Deaquí a 2030, asegurar el acceso igualitario de todos los hombres y las mujeres a una formación técnica, profesional y superior de calidad, incluida la enseñanza universitaria META
  • 5.
    2.2 Rest yRestFul
  • 6.
    ¿Qué es REST? ●Origen: Fielding, Roy T. “Architectural Styles and the Design of Network-based Software Architectures.” Tesis Doctoral, Universidad de California, 2000. ● Describe un estilo de arquitectura que utilizar como modelo en los servicios de computación Web. ● Estilo de arquitectura: Conjunto coordinado de restricciones que controlan el funcionamiento y características de los elementos de la arquitectura y permite las relaciones de unos con otros. ● Describe cómo debería comportarse la Web ● NO es un estándar
  • 7.
    ¿Por qué hatriunfado la Web? ● Escalabilidad en interacciones entre componentes ● Generalidad en las interfaces ● Desarrollo independiente de componentes ● Existencia de componentes intermediarios (proxys)
  • 8.
    Principios de REST ●El estado y la funcionalidad de las aplicaciones se divide en recursos ○ REST es orientado a recursos y no a métodos ○ No se accede directamente a los recursos, sino a representaciones de los mismos Servicio Acceso CUENTA BANCARIA =123 USUARIO Recurso CUENTA BANCARIA =123 USUARIO Sistema basado en REST Sistema basado en SOAP
  • 9.
    Principios de RESTII ● Todo recurso es identificado de forma única global mediante una sintaxis universal. Como en HTTP los recursos se identifican mediante URIs (Uniform Resource Identifier). ○ Conjunto potencialmente infinito de recursos. ● Todos los recursos comparten un interfaz uniforme formado por: ○ Conjunto de operaciones limitado para transferencia de estado ■ En HTTP GET, PUT, POST, DELETE ○ Conjunto limitado de tipos de contenidos ■ En HTTP se identifican mediante tipos MIME: XML , HTML...
  • 10.
    Principios de RESTIII ● Un protocolo cliente/servidor, sin estado y basado en capas ● Cada mensaje contiene la información necesaria para comprender la petición (mensajes autocontenidos, como HTTP) RED ESTADO A ESTADO B ESTADO C ESTADO A ESTADO B ESTADO C
  • 11.
    Principios de RESTIV ● Uso de hipermedios, tanto para la información de la aplicación como para las transiciones de estado de la aplicación. ● A través de sucesivas peticiones de recursos cambia el estado de la aplicación.
  • 12.
    Principios de RESTV ● Promueve mecanismos caché y sistemas intermedios
  • 13.
    Ventajas de REST ●Mejora el tiempo de respuesta gracias al mecanismo Caché y los mensajes auto-descriptivos. ● Disminución de carga en servidor ● Mayor escalabilidad al no requerir mantenimiento de estado en el servidor ● Facilita desarrollo de clientes (menor dependencia del servidor). ● Mayor estabilidad frente a futuros cambios ○ Permite evolución independiente de los tipos de documentos al procesar éstos en el cliente.
  • 14.
    Diferencias entre RESTy SOAP SOAP REST Orientado a RPC Orientado a recursos Servidor almacena parte del estado El estado se mantiene sólo en el cliente, y no se permiten las sesiones Usa HTTP como túnel para el paso de mensajes Propone HTTP como nivel de aplicación
  • 15.
    Ejemplo ● Sistema basadoen SOAP ○ Énfasis en diversidad de operaciones (verbos) getUser() addUser() removeUser() updateUser() getLocation() addLocation() removeLocation() updateLocation()  Sistema REST  Énfasis en diversidad de recursos (nombres) User {} Location{}  Registro del recurso User (accesible con HTTP GET): <usuario> <nombre>Benito Pérez</nombre> <genero>masculino</genero> <localizacion href="http://www.example.org/locations/ spain/oviedo"> Oviedo, Spain </localizacion> </usuario>
  • 16.
    Soap vs REST:Críticas ● SOAP no es transparente, apuesta por el encapsulamiento ● SOAP no dispone de un sistema de direccionamiento global ● SOAP puede derivar en agujeros de seguridad ● SOAP no aprovecha muchas de las ventajas de HTTP al usarlo solamente como túnel ● SOAP no puede hacer uso de los mecanismos Caché ● REST es poco flexible ● REST no está preparado para albergar Servicios Web de gran complejidad como las aplicaciones B2B ● REST tiene grandes problemas de seguridad al no soportar el concepto de sesión
  • 17.
    Uso de REST ●Adecuado para grandes cantidades de información pública para grupos desconocidos de usuarios ● No adecuado para sistemas complejos cerrados
  • 18.
    Ejemplo de Implementaciones ●AMAZON ○ Pionera en el uso de REST en 2002 ○ Base de datos con todos los productos que vende ○ Los productos se acceden como recursos, no como métodos de búsqueda ○ API disponible en associates.amazon.com ○ Posible carencia, si realiza servicios más sofisticados puede que deba migrar a SOAP ● EBAY ○ Desarrolló una API REST en 2004 ○ Consulta de productos a través del método GetSearchResults() ● OTROS: YOUTUBE, YAHOO, FLICKR, etc..
  • 19.
    Visión general conceptual Definiciónde servicio web RESTful ● Un servicio web RESTful es: ○ Un conjunto de recursos web. ○ Interrelacionadas. ○ Centrado en datos, no centrado en la funcionalidad. ○ Orientado a la máquina. ○ Como las aplicaciones web, pero para máquinas. ○ Como WS-*, pero con más recursos web. WS-* representa una variedad de especificaciones relacionadas con los servicios web basados en SOAP.
  • 20.
  • 21.
    ● Un servicioSOAP (WS) tiene un único extremo que controla todas las operaciones, por lo que tiene que tener una interfaz específica de la aplicación. ● Un servicio RESTful tiene una serie de recursos (la colección, cada entrada), por lo que las operaciones se pueden distribuir en los recursos y asignarse a un pequeño conjunto uniforme de operaciones.
  • 22.
    Futuro de REST ●SOAP mantiene el monopolio de los Servicios Web ● Carencia de documentación ● Escasas implementaciones y ejemplos prácticos para acercar REST al programador común ● Única solución, crear organización o entidad que agrupe el disperso y escaso trabajo que existe sobre REST
  • 23.