UTM, Aguaszoft

1. Facultad de Ciencias Informáticas
Desarrollo de Aplicaciones Web
Unidad 2 Programación web en el
servidor
PhD(c). Luis Fernando Aguas Bucheli
+593 984015184
@Aguaszoft
luis.aguas@utm.edu.ec

2. Objetivos de Desarrollo Sostenible
Meta
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

3. El dinero no es la clave del éxito; la libertad para
poder crear lo es - Nelson Mandela

4. Resultado de Aprendizaje
• Diseñar un producto de
software en el que se
apliquen principios de
diseño, para que sea
robusto, fácil de mantener
y modificar
Contenido
• Unidad 2 Programación web en
el servidor
• 2.1.2 API REST
• 2.1.3 Patrón Modelo-Vista-
Controlador

5. ¿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

6. ¿Por qué ha triunfado la Web?
• Escalabilidad en interacciones entre componentes
• Generalidad en las interfaces
• Desarrollo independiente de componentes
• Existencia de componentes intermediarios (proxys)

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

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

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

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

11. Principios de REST V
• Promueve mecanismos caché y sistemas intermedios

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

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

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

15. Uso de REST
• Adecuado para grandes cantidades de información pública para
grupos desconocidos de usuarios
• No adecuado para sistemas complejos cerrados

16. 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..
• En ocasiones siguen la arquitectura “sin querer”.

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

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

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

21. Conceptos de MVC
• Un patrón de diseño permiten solucionar problemas comunes que se
presentan al momento de crear aplicaciones, y en particular en
aplicaciones Web nos interesa separar la vista de los datos (modelo) y
unirlos por medio de un componente que hace la vez de controlador.
• Los Servlets están enfocados en controlar el flujo de la aplicación y en
este caso procesan las peticiones HTTP, así como utilizar los JavaBean
para almacenar información y finalmente redireccionar al JSP
respectivo.

23. Frameworks MVC
• Existe varios Frameworks que implementan ya este patrón, un patrón
de diseño es simplemente una guía, por lo tanto cada uno de estos
Frameworks tanto Struts, JavaServer Faces, Spring MVC, entre otros.
• Por ejemplo en el caso del Framework de Struts es un framework de
Apache, el cual utiliza JSPs como la Vista utilizando también a su vez
tags de Struts, posteriormente utiliza el concepto llamado ActionForm
que de alguna manera sustituye a los JavaBeans, siendo el modelo de
nuestra aplicación y finalmente tenemos el concepto de Action, el cual
cubre el rol del controlador. Estos son simplemente algunos
componentes de los que se manejan dentro del Frameworks de Struts.

24. Frameworks MVC
• JavaServer Faces es una tecnología definida por Sun Microsystems, en el cual
se utilizan conceptos como son los mismos JSPs pero utilizando tags de JSF.
• JavaBeans para manejar el concepto de modelo aunque también cabe
resaltar que los ManagedBean pueden jugar el rol tanto de controlador
como de modelo, entonces todo podría mezclarse en un solo bean y se
podría omitir el uso de los JavaBeans.
• Spring MVC, es una extensión de Spring, en el cual se utilizan JSPs como
parte la vista y se pueden utilizar los tags de Spring para robustecer estos
JSPs.

26. Arquitectura MVC con JSP y Servlets
• Una vez que el JSP genera el HTML utilizando la información de los
JavaBeans que el Servlets le proporcionó, lo que hace es regresar el
contenido al cliente y en este momento es cuando se genera el Render
de nuestra aplicación según el Content Type que hayamos utilizado. Por
ejemplo, puede ser una salida en HTML, PDF, Video, un archivo de Excel,
etc. según hemos visto anteriormente.
• El punto es que el JSP únicamente va a desplegar la información que
recibió del Servlet y enviará esta información al cliente. Con esto
termina el flujo y si el cliente necesitara de realizar una nueva petición el
proceso se repite nuevamente.

28. Servlet Controlador
• Según revisamos en la teoría de los Servlets, para procesar un parámetro
podemos utilizar la siguiente notación:
request.getParameter(“nombreParametro”);
• Podemos validar los parámetros para saber si la información que estamos
recibiendo es correcta.
• Una vez que ya hemos procesado los parámetros podemos realizar la
lógica de presentación respectiva o la lógica de negocio utilizando
JavaBeans
• Debemos de compartir el objeto que estamos creando en algún alcance

29. Servlet Controlador
• En este caso, por medio del método forward estamos
proporcionando y enviando toda la información necesaria al JSP
para que no tenga ningún problema y pueda acceder a la
información que hemos compartido previamente por medio del
Servlet.

30. Gracias
Somos UTM