Web Services

Introducción a las aplicaciones web

Ing. Lisandra Madero Lorenzo

Especialista C en Ciencias Informáticas
División Habana
La Habana, 22 de septiembre del 2014
[email protected]

Informatizamos para la Sociedad Cubana

 Aplicaciones web
Inicialmente la web era simplemente una colección
de páginas estáticas, documentos, etc., que podían
consultarse o descargarse.

El siguiente paso en su evolución fue la inclusión de

un método para confeccionar páginas dinámicas
que permitiesen que lo mostrado fuese dinámico
(generado o calculado a partir de los datos de la
petición).
 Aplicaciones web
Dicho método fue conocido como CGI (common
gateway interface) y definía un mecanismo
mediante el cual podíamos pasar información entre
el servidor HTTP y programas externos.

El esquema de funcionamiento de los CGI tenía un

punto débil: cada vez que recibíamos una petición,
el servidor web lanzaba un proceso que ejecutaba
el programa CGI.
 Aplicaciones web
Por ello se empiezan a desarrollar alternativas a los
CGI para solucionar este grave problema de
rendimiento. Las soluciones vienen principalmente
por dos vías.

1)Por un lado se diseñan sistemas de ejecución de

módulos más integrados con el servidor, que evitan
que éste tenga que instanciar y ejecutar multitud de
programas.
 Aplicaciones web
2) La otra vía consiste en dotar al servidor de un
intérprete de algún lenguaje de programación
(RXML, PHP, VBScript, etc.) que nos permita incluir
las páginas en el código de manera que el servidor
sea quien lo ejecute, reduciendo así el tiempo de
respuesta.
A partir de este momento, se vive una explosión del
número de arquitecturas y lenguajes de
programación que nos permiten desarrollar
aplicaciones web.
 Aplicaciones web
Todas ellas siguen alguna de las dos vías ya
mencionadas. De ellas, las más útiles y las que más
se utilizan son aquellas que permiten mezclar los
dos sistemas, es decir, un lenguaje de programación
integrado que permita al servidor interpretar
comandos que “incrustemos” en las páginas HTML
y un sistema de ejecución de programas más
enlazado con el servidor que no presente los
problemas de rendimiento de los CGI.
 Terminología y conceptos

Web Services: describe una forma

estandarizada de integrar aplicaciones
web mediante el uso de varias
tecnologías.

A diferencia de los modelos

Cliente/Servidor, tales como un servidor de
páginas web, los Web Services no proveen
al usuario una interfaz gráfica, en vez de
ello, comparten la lógica del negocio, los
datos y los procesos , por medio de una
interfaz de programas a través de la red.
 Fundamentos de la web
El éxito espectacular de la web se basa en dos puntales
fundamentales: el protocolo HTTP y el lenguaje HTML.

•Uno permite una implementación simple y sencilla de un sistema

de comunicaciones que nos permite enviar cualquier tipo de
ficheros de una forma fácil, simplificando el funcionamiento del
servidor y permitiendo que servidores poco potentes atiendan
miles de peticiones y reduzcan los costes de despliegue.

•El otro nos proporciona un mecanismo de composición de páginas

enlazadas simple y fácil, altamente eficiente y de uso muy simple.
 El protocolo HTTP
El protocolo HTTP (Hypertext Transfer Protocol) es el protocolo base de
la WWW. Se trata de un protocolo simple, orientado a conexión y sin
estado.
HTTP utiliza el puerto 80 (equivalente de alguna forma al identificador
de conexión o de servicio TCP) para todas las conexiones por defecto
(podemos utilizar otros puertos diferentes del 80).
Existe una variante de HTTP llamada HTTPS (S por secure) que utiliza el
protocolo de seguridad SSL (secure socket layer) para cifrar y autenticar
el tráfico entre cliente y servidor, siendo ésta muy usada por los
servidores web de comercio electrónico, así como por aquellos que
contienen información personal o confidencial.
HTTPS utiliza por defecto el puerto 443.
 El protocolo HTTP
De manera esquemática, el funcionamiento de HTTP es el siguiente: el
cliente establece una conexión TCP hacia el servidor, hacia el puerto
HTTP (o el indicado en la dirección de conexión), envía un comando
HTTP de petición de un recurso (junto con algunas cabeceras
informativas) y por la misma conexión el servidor responde con los
datos solicitados y con algunas cabeceras informativas.
Petición
Cliente GET/Index.html
(Navegad
or)

Servidor
Respuesta (Servidor
HTTP/1.1 200 Content-type. Web)
Text/html
<html>
…
 El protocolo HTTP
El protocolo define además cómo codificar el paso de parámetros entre páginas, el
tunelizar las conexiones (para sistemas de firewall), define la existencia de servidores
intermedios de cache, etc. Las directivas de petición de información que define HTTP
1.1 (la versión considerada estable y al uso) son:
o GET Petición de recurso.
o POST Petición de recurso pasando parámetros.
o HEAD Petición de datos sobre recurso.
o PUT Creación o envío de recurso.
o DELETE Eliminación de recurso.
o TRACE Devuelve al origen la petición tal como se ha recibido en el receptor, para
depurar errores.
o OPTIONS Sirve para comprobar las capacidades del servidor.
o CONNECT Reservado para uso en servidores intermedios capaces de funcionar
como túneles.
 El protocolo HTTP
Detallaremos a continuación algunos de estos comandos, ya que su
comprensión es fundamental para el desarrollo de aplicaciones web.

Cabe destacar que todos los recursos que sean servidos mediante HTTP
deberán ser referenciados mediante una URL (uniform resource locators).

•Peticiones en HTTP: GET y POST

Las peticiones en HTTP pueden realizarse usando dos métodos. El método

GET, en caso de enviar parámetros junto a la petición, las enviaría codificadas
en la URL. Por su parte, el método POST, en caso de enviarlos, lo haría como
parte del cuerpo de la petición.
 El protocolo HTTP
Una petición GET persigue el siguiente formato:

GET /index.html HTTP/1.1

Host: www.ejemplo.com
User-Agent: Mozilla/4.5 [en]
Accept: image/gif, image/jpeg, text/html
Accept-language: en
Accept-Charset: iso-8859-1
 El protocolo HTTP
Podemos ver que está formada por:

1. Línea de petición: contiene el recurso solicitado.

2. Cabecera de petición: contiene información adicional sobre el cliente.
3. Cuerpo de petición: en las peticiones de tipo POST, y otras, contiene
información adicional.

•Línea de petición
La línea de petición está formada por los siguientes elementos:

1. Método: nombre del método de HTTP llamado (GET, POST, etc.).

2. Identificador de recurso: URL del recurso solicitado.
3. Versión de protocolo: versión del protocolo solicitada para la respuesta.
 El protocolo HTTP
• Cabecera de petición

Contiene información adicional que puede ayudar al servidor (o a los

servidores intermedios, los proxys y caches) a procesar adecuadamente la
petición.

La información se proporciona en forma de: Identificador: valor

De estos identificadores, los más conocidos e importantes son:

Host: nombre del servidor solicitado.

User-Agent: nombre del navegador o programa usado para acceder al recurso.
Accept: algunos formatos de texto e imagen aceptados por el cliente.
Accept-Language: idiomas soportados (preferidos) por el cliente, útil para
personalizar la respuesta automáticamente.
 El protocolo HTTP
•Parámetros de petición

Una petición HTTP puede también contener parámetros, como respuesta,

por ejemplo, a un formulario de registro, a una selección de producto en una
tienda electrónica, etc. Estos parámetros pueden pasarse de dos formas:

– Como parte de la cadena de petición, codificados como parte de la URL.

– Como datos extra a la petición.

 El protocolo HTTP
Para codificar los parámetros como parte de la URL, éstos se añaden a la URL
detrás del nombre del recurso, separados de éste por un carácter ?. Los
diferentes parámetros se separan entre sí por el carácter &. Los espacios se
sustituyen por +.

Por último, los caracteres especiales (los mencionados antes de &, + y ?, así
como los caracteres no imprimibles, etc.) se representan con %xx, donde xx
representa al código ASCII en hexadecimal del carácter.

Por ejemplo:

http://www.ejemplo.com/indice.jsp?nombre=Perico+Palotes&OK=1
 El protocolo HTTP
En la petición HTTP quedaría:

GET /indice.jsp?nombre=Perico+Palotes&OK=1 HTTP/1.0

Host: www.ejemplo.com
User-Agent: Mozilla/4.5 [en]
Accept: image/gif, image/jpeg, text/html
Accept-language: en
Accept-Charset: iso-8859-1
 El protocolo HTTP
Para pasar los parámetros como datos extra de la petición, éstos se envían al
servidor como cuerpo de mensaje en la petición.

Por ejemplo, la petición anterior quedaría:

POST /indice.jsp HTTP/1.0

Host: www.ejemplo.com
User-Agent: Mozilla/4.5 [en]
Accept: image/gif, image/jpeg, text/html
Accept-language: en
Accept-Charset: iso-8859-1
nombre=Perico+Palotes&OK=1
 El protocolo HTTP
Cabe destacar que para pasar los parámetros como cuerpo de la petición,
ésta debe realizarse como POST y no como GET, aunque una petición
POST también puede llevar parámetros en la línea de petición.

Los parámetros pasados como cuerpo de la petición están codificados, al

igual que en el ejemplo anterior, como URL, o pueden usar una
codificación derivada del formato MIME (multipurpose internet mail
extensions), en lo que se conoce como codificación multiparte.
 El protocolo HTTP
Respuestas en HTTP

Las respuestas en HTTP son muy similares a las peticiones. Una respuesta
estándar a una petición de una página sería similar a lo siguiente:

HTTP/1.1 200 OK
Date: Mon, 04 Aug 2003 15:19:10 GMT
Server: Apache/2.0.40 (Red Hat Linux)
Last-Modified: Tue, 25 Mar 2003 08:52:53 GMT
Accept-Ranges: bytes
Content-Length: 428
Connection: close
<HTML>
...
 El protocolo HTTP
En ella podemos observar que la primera línea nos responde con la versión del
protocolo empleada para enviarnos la página, seguida de un código de retorno y
una frase de retorno. El código de retorno puede adoptar uno de los siguientes
valores:

– 1xx Petición recibida, continúa en proceso.

– 2xx Correcta. Petición procesada correctamente.
– 3xx Redirección. La petición debe repetirse o redirigirse.
– 4xx Error de cliente. No se puede procesar la petición porque ésta es incorrecta,
no existe, etc.
– 5xx Error de servidor. El servidor ha fallado intentando procesar la petición, que a
priori es correcta.
 El protocolo HTTP
La frase de retorno dependerá de la implementación, pero sólo sirve como
aclaratorio del código de retorno.

Después del estatus aparece una serie de campos de control, con el mismo
formato que en las cabeceras de la petición que nos informan del contenido
(fecha de creación, longitud, versión del servidor, etc.).

A continuación viene el contenido solicitado.

 El lenguaje HTML
El otro puntal del éxito del WWW ha sido el lenguaje HTML (hypertext mark-up
language).

Se trata de un lenguaje de marcas (se utiliza insertando marcas en el interior

del texto) que nos permite representar de forma rica el contenido y también
referenciar otros recursos (imágenes, etc.), enlaces a otros documentos (la
característica más destacada del WWW), mostrar formularios para
posteriormente procesarlos, etc.

El lenguaje HTML actualmente se encuentra en la versión 5 y empieza a

proporcionar funcionalidades más avanzadas para crear páginas más ricas en
contenido.

Además se ha definido una especificación compatible con HTML, el XHTML

(extensible hypertext markup language) que se suele definir como una versión
XML validable de HTML, proporcionándonos un XML Schema contra el que
validar el documento para comprobar si está bien formado, etc.
Fin
 XML
• Abreviación de Extensible Markup Language. El
XML es una especificación desarrollada por W3C
(world wide web Consortium). Permite a los
desarrolladores crear sus propios tags, que les
permiten habilitar definiciones, transmisiones,
validaciones, e interpretación de los datos entre
aplicaciones y entre organizaciones.
 SOAP
• Abreviación de Simple Object Access Protocol, es
un protocolo de mensajería construido en XML
que se usa para codificar información de los
requerimientos de los Web Services y para
responder los mensajes antes de enviarlos por la
red. Los mensajes SOAP son independientes de
los sistemas operativos y pueden ser
transportados por los protocolos que funcionan
en la Internet, como: SMTP, MIME y HTTP.
 WSDL
• Abreviación de Web Services Description Language,
es un lenguaje especificado en XML que se ocupa
de definir los Web Services como colecciones de
punto de comunicación capaces de intercambiar
mensajes, es un estándar de uso público.
 UDDI
• Abreviación de Universal Description Discovery and
Integration. Es un directorio distribuido que opera
en la Web que permite a las empresas publicar sus
Web Services, para que otras empresas conozcan y
utilicen los Web Services que publican.