S4-PD2-REST-REST FULL

1. Plataformas de
Desarrollo 2
Tema: 2 Web Services
Mg. Luis Fernando Aguas Bucheli
+593 984015184
@Aguaszoft
Laguas@uisrael.edu.ec

2. “La vida es mejor para aquellos que hacen lo
posible para tener lo mejor” – John Wooden.

3. 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

4. Objetivos de Desarrollo Sostenible
4.7 De aquí a 2030, asegurar que todos los alumnos adquieran
los conocimientos teóricos y prácticos necesarios para
promover el desarrollo sostenible, entre otras cosas mediante la
educación para el desarrollo sostenible y los estilos de vida
sostenibles, los derechos humanos, la igualdad de género, la
promoción de una cultura de paz y no violencia, la ciudadanía
mundial y la valoración de la diversidad cultural y la
contribución de la cultura al desarrollo sostenible

5. 2.2 Rest y RestFul

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é ha triunfado 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 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...

10. 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

11. 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.

12. Principios de REST V
● 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 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

15. 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>

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ó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.

20. WS-
collection
service
collection
entry
entry
entry
listEntries()
addEntry()
getEntry()
deleteEntry()
updateEntry()
listEntries()
addEntry()
getEntry()
deleteEntry()
updateEntry()
RESTful

21. ● 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.

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. Gracias
Responsabilidad con pensamiento positivo