Construyendo un Cliente HTTP tipo Escritorio – Parte I

Cordial saludo para todos.

En este segundo artículo dedicado a enseñarles algunos tips sobre sistemas distribuidos, voy a mostrarles como construir un sistema distribuido basado en el protocolo HTTP, no es el típico la típica aplicación Web que necesita de un navegador Web, el cual hace una petición al servidor web y este le responde generalmente con la información que debe mostrar (condonación de HTML, CSS, JavaScript y archivos multimedia), esta vez se trata de una aplicación web cuyo cliente lo desarrollaremos nosotros mismos,  la información que llega al cliente emitida por  al servidor cada vez que le realiza una petición, estará forma por documentos XML, los cuales serán procesado por el cliente con el fin de obtener la información contenida en ellos y poder mostrarla en controles para interfaces graficas para aplicaciones de escritorio.

Este tipo de aplicaciones web tienen algunos beneficios que no poseen las aplicaciones web basadas en contendeos HTML, como por ejemplo:

• El cliente posee la gran mayoría del código que se utiliza como interfaz de usuario, algo de lo que carecen casi en su mayoría las aplicaciones web cuyo cliente es un navegador web, este obviamente es un factor que aumenta considerablemente el desempeño, eficiencia y rapidez del sistema, dado que el cliente no tiene que recibir y procesar código de interfaz de usuario, solo recibe los dato que tiene que mostrar en sus propias interfaces.
• El servidor se dedica a operaciones de negocio y no a generar las interfaces graficas que debe mostrar el cliente, esta característica libera los recursos del servidor utilizados por las aplicaciones web tradicionales, aumentando el desempeño del servidor y por ende procesado  un mayor número de peticiones.
• Pueden coexistir muchos clientes escritos en diferentes lenguajes y con diferentes GUIs.

Como todo en este mundo, también tiene desventajas:

Para utilizar el aplicativo cliente se debe disponer de una instalación previa en el PC desde donde el usuario realiza las conexiones al servidor

Hay que desarrollar las respectivas actualizaciones en todas las versiones de clientes que deseen conectase al servidor, dado que el ellos se encuentra la GUI.

Si un documento XML cambia obligatoriamente debe cambiar el modulo del cliente que procesa este XML.

Recordando el protocolo HTTP

El HipetText Transfer Protocolo o HTTP es uno de los primeros protocolos de servicios que se establecieron con gran existo en internet, se puede decir que internet es lo que hoy en día gracias a la invención de este importante protocolo de servicios de red, gracias a HTTP podemos ver todas absolutamente todas las páginas web que existen en internet o  en una intranet, otros servicios igualmente populares de internet, dependen en gran medida de este protocolo, tal es el caso de los servicios de mensajería por correo electrónico, algunos canales de noticas,  las súper exitosas redes sociales, las bibliotecas abiertas y privadas, el mundo del software libre es uno de los más beneficiados por el protocolo HTTP, algunos canales de internet, y no podían faltar los sistemas de gestión empresarial, como ERPs, CRMs, virtual Store, CMS, y hasta el aprendizaje a distancia y en línea o E-learning.

La estructura básica del protocolo se rige como cualquier otro en una seria de reglas establecidas en el documento RFC-2616, el cual pueden ver en su formato original, pero básicamente indica de qué manera el cliente Web debe realizar una petición de recursos HTTP (pagina web u otro tipo de archivo) y como se debe el servidor web realizar la respuesta HTTP para dicha petición.

Una petición está compuesta por los siguientes elementos:

• URL: Uniform Resource Locator o localizador universal de recursos, más conocida como dirección web, se trata de una norma internacional que permite localizar un recurso (archivo) en internet o en una red TCP/IP, la URL está formada a su vez de:

PROTOCOLO://NOMBRE_DE_DOMINIO_O_DIRECCION_IP:PUERTO/URI

Donde PROTOCOLO representa el tipo de protocolo con el cual se desea realizar la petición, para el caso de http, existen dos posibilidades, HTTP:// o HTTPS://, el primero envía los datos en texto sin formato (texto plano), legible por cualquiera que medio entienda de informática, el segundo envía los datos en formato criptográfico, es decir, los codifica o encripta para hacer ilegible la información por elementos que intervengan de forma silenciaos o clandestina y no autorizados entre la conexión del cliente y el servidor.

NOMBRE_DE_DOMINIO_O_DIRECCION_IP representa el nombre que identifica al host  servidor (host es un sinónimo de dispositivo conectado a la red, PC, Router, Radio, teléfono móvil, PDA, cámara etc.) en la red (internet o intranet), si no se dispone de un nombre de dominio, se puede sustituir este por la respectiva dirección IP del Host servidor.

UERTO es el numero de puerto de red asignado por el Sistema Operativo al proceso servidor, este número es entero y puede estar en el rango de 0 a 65535, para el caso del protocolo HTTP la IAN ya le asignado un puerto predeterminado, este número es el 80, lo que quiere decir que por norma se recomienda que los servidores http, inicien con la atención de peticiones por el puerto 80, esta norma permite que el puerto sea omitido de la URL si corresponde al número 80, de lo contrario había que especificarlo de forma explícita dentro de la URL, por ejemplo,  si un servidor http cualquiera se llamase miservidorweb y su dirección IP fuese 192.168.1.17, además estuviese  atendiendo peticiones http por el puerto estándar y todas las condiciones de conexión de red son correctas, podríamos hacer una petición desde una navegador web (cliente HTTP por estándar) utilizando cualquiera de las  siguientes URL http://miservidorweb/URI o http://192.280.1.17/URI http://miservidorweb:80/URI o http://192.280.1.17:80/URI. Si por el contrario las peticiones atendiera desde el puerto 7000, tendríamos que realizar las peticiones colocando explícitamente el numero de puerto utilizado por el servidor, http://miservidorweb:7000/URI o http://192.280.1.17:7000/URI.

/URI significa  Uniform Resource Identifier o identificador uniforme de recursos, es la parte de la URL que permite identificar inequívocamente dentro del servidor  al recurso que se desea obtener desde el proceso cliente, la URI comúnmente es una ruta de ficheros relativa al directorio de recursos públicos que ofrecidos por el servidor, otras veces es una dirección virtual, es decir, ruta relativa real del recurso se encuentra enmascarada (oculta) por una dirección irreal, también conicidad como alias, por ejemplo, si el servidor http hipotético del ejemplo anterior almacena los recursos que ofrece a los clientes en un directorio llamado public_html, además si por ejemplo dentro de este directorio existe un subdirectorio llamado mistioweb, el cual a su vez contiene dos  archivos llamados mipaginaweb.html e index.html, entonces, las posibles URI que deberíamos escribir desde es el proceso cliente son /misitioweb/mipaginaweb.html, /misitioweb/index.html, el cual también se puede llamar por /misitioweb/, nótese que la no se incluye el nombre del directorio publico del servidor o directorio de servicio, también conocido como hosting o lugar de hospedaje, /misitioweb es el directorio raíz (document root) dentro del hosting, nótese también que cuando existe un archivo llamado index.html (archivo índice o archivo de inicio), no es necesario especificar su nombre, puesto que es un estándar para el protocolo HTTP que si se omite el nombre del fichero recurso, entonces se entiende que se está solicitando un fichero llamado index.html, de lo contrario si este fichero no existe y el servidor http tiene habilitada la lista de directorios, entonces se mostrar el contenido del directorio raíz  o del directorio que estuviese en su lugar, si no está habilitada la lista de directorios en servidor http, este responderá al cliente http con un código de respuesta (código de estado), que para este caso sería el código 404, cuya explicación breve es  File Not Found o archivo no encontrado, el código para indicar que el fichero solicitado esta disponible es 200, cuyo breve mensaje explicativo es OK.

Según lo que explicado  aquí  y siguiendo el mismo hipotético ejemplo, para hacer peticiones al servidor darían como resultado el código 200:

http://192.280.1.17:80/misitioweb/mipaginaweb.html

http://192.280.1.17/misitioweb/mipaginaweb.html

http://miservidorweb:80/misitioweb/mipaginaweb.html

http://miservidorweb/misitioweb/mipaginaweb.html

http://miservidorweb:80/misitioweb/index.html

http://192.280.1.17:80/misitioweb/index.html

http://192.280.1.17/misitioweb/index.html

http://miservidorweb/misitioweb/index.html

http://miservidorweb:80/misitioweb/

http://192.280.1.17:80/misitioweb/

http://192.280.1.17/misitioweb/

http://miservidorweb/misitioweb/

• El cuerpo de la petición.

Además de la URL, la petición lleva consigo un serie de datos que conforman una especie de etiqueta de presentación del cliente http ante al servidor http, estos datos son muy importantes para el servidor, puesto que con ellos puede tomar decisiones que afecten para bien o para mal la comunión entre ambos proceso, entre los datos que se envía adjuntos con la URL son:

Método_de_peticio /URI?cadena_de_consulta versión_protocolo_http

• • Método_de_peticio pueden ser uno de estos  GET, POST, TRACE, PUT, OPTION, CONNECT y DELETE, donde en realidad la gran mayoría de particiones http se hacen utilizando ya sea el método GET o el método POST,

• • El método GET es muy  utilizado por el cliente http para solicitar un recursos, donde la petición no requiera enviar más de 1024 bytes (1024 caracteres) al servidor.

• • El método POST es muy utilizado por el cliente http para solicitar un recursos, pero junto a la petición también se envían considerables cantidades de datos, siendo este tamaño ilimitado.

• • La URI corresponde a la identificación del recurso solicitado en el servidor, ?cadena_de_consulta solo es válido para peticiones con el método GET,  esta cadena es una seria de parámetros que pueden ser enviados por el cliente http adjuntos a la petición, estos parámetros son recuperados del lado del servidor y procesados por alguna aplicación que se está ejecutando, normalmente dicha aplicación corresponde al mismo recurso solicitado con la petición que envía dichos  parámetros, http estable el siguiente formato para enviar parámetros en una petición con el método GET, URI?nombre_parametro1=valor&nombre_parametro2=valor&nombre_parametroi=valor&nombre_parametroN=valor
  • Ejemplo: si un cliente http mediante una petición http con método GET desea solicitar el recurso mipaginaweb.php, ubicado en el dentro del directorio raíz misitioweb de nuestro servidor http con nombre de dominio miservidorweb, y de paso el cliente http desea enviar el código y el password como parámetros en esta petición, tendríamos que escribir la siguiente URL http://miservidorweb/misitioweb/mipaginaweb.php?login=johnarrieta&password=123.
  • versión_protocolo_http corresponde a la versión del protocolo http que está utilizando el cliente http para realizar la petición, esta información es utilizada por el servidor http para determinar cómo debe realizar  la respuesta de la petición hecha por el cliente, para peticiones hechas utilizando cualquiera de los métodos GET, POST, TRACE, PUT, OPTION, CONNECT y DELETE el valor para la versión del protocolo http puede ser HTTP/1.0 o HTTP/1.1

• Cabeceras de Petición

El cliente http después de colocar en la en la primera línea de la petición información correspondiente al Método, la URI y la Versión del Protocolo, también envía otro tipo de acerca de sus características como su nombre y versión, el idioma en el que está escrito, el tipo de sistema de codificación que utiliza , el tipo de contenidos que acepta, la fecha y hora en realizo la petición, el nombre y versión del sistema operativo y del HOST sobre el cual se ejecuta, el tamaño de datos que se envían con la petición, etc.

Estas cabeceras tienen un nombre estándar dentro del protocolo http y se envían con su valor cada una en líneas separada per ejemplo:

El servidor http puede utilizar el valor contenido en estas cabeceras  de petición para realizar tareas propias de la respuesta que debe entregar al cliente http, por ejemplo puede utilizar la cabecera Accept-language para determinar en qué idioma va a entregar el contenido de la respuesta que se va a mostrar en el cliente, también puede utilizar la cabecera Accept para determinar si debe  o no debe  enviar algún tipo de contenido especifico (imagen, archivo de multimedia, html, etc..) al cliente, la cabecera Content-Type para saber si la peticion trae adjunto al menos un archivo, etc.

Ejemplo del contenido de una petición HTTP que envía parámetros al servidor mediante el método GET:

Ejemplo de una petición HTTP sin envió de parámetros al servidor mediante el metido GET:

Ejemplo de una petición HTTP que envió de parámetros al servidor mediante el metido POST:

La respuesta HTTP del servidor

Una vez el cliente HTTP ha enviado su petición al servidor HTTP, esta petición sale del host del cliente y es dirigida por la red hacia el host del servidor, el servidor acepta la petición e inicia con el procesamiento de los datos que se envían junto a ella, la tarea básica del servidor es almacenar toda la información de la petición en variables, esto con el fin de poder utilizarla cada vez que lo desee mientras dura el procesamiento de la petición hasta que se emite su respectiva respuesta.

• Recupera los datos de la primera línea y los almacena en variables independientes Method=”GET” URI = “mipaginaweb.php” QuieryString = “codigo=johnarreita&password=123”
• Recupera las cabeceras y las guarda en una estructura de datos generalmente un arreglo referenciado también conocido como mapa HEADERS=”Host”->”miservidorweb”, “User-Agent”->”Mozilla/4.5 [en]”, “Accept”->”image/jpeg, image/gif, text/html”, “Accept-language”->”es”,” Accept-Charset”->” iso-8859-1”,” Date”->” Tue, 14 Oct 2009 07:17:57 GMT”, de esta forma los lenguajes de programación interesados en subprocesar las peticiones puedan obtener la información mesaría desde estas variables
• Analiza la URI y verifica la extensión del recurso que fue solicitado, si es en fichero procesable por el servidor HTTP (.html, .txt, .htm, .gif, .swf, etc.) entonces busca este fichero en la ruta indicada por el URI, si lo encuentra guarda un apuntador hacia el, arma una respuesta colocando datos como algunas cabeceras importantes para el cliente y luego  abre el fichero y va enviando partes de su contenido al cliente, cerrando la conexión cuando haya terminado el envió del último byte de la respuesta.

Si por el contrario, la extensión del fichero no es compatible con los tipos de archivos que puede procesar el servidor, entonces busca en su archivo de configuración cual es el programa (generalmente un intérprete, para el caso de PHP, JSP y ASP) encargado de procesar peticiones con ese tipo de archivo, si lo encuentra,  entrega la petición a este programa para que inicie con el procesamiento de la petición, colocando a su disposición toda la información recuperada de la petición, en ultimas el programa ejecuta el fichero (recurso) solicitado y envía la salida generada al cliente http, notificando al servidor http cuando ha finalizado el procesamiento de la petición, para que este termine con la conexión entre cliente y servidor.

Si el servidor http no logra encontrar en su archivo de configuración un programa que pueda atender la petición del recurso solicitado, entonces, busca el recurso, arma una respuesta a la petición y entrega el contenido original del recurso solicitado, si el recurso es PHP, JSP o ASP, envía el código fuente al cliente de este recurso, el cliente lo recibe pero como no puede interpretarlo (recordemos que el interprete debía estar en ejecución en el host del servidor), termina por mostrar todo el código fuente del recurso solicitado.

El cuerpo de la respuesta HTTP

Al igual que ocurre con el cliente http, el servidor entrega una respuesta armada según el estándar del protocolo HTTP, el cual indica que debe llevar:

• En la primera línea  la versión del protocolo HTTP utilizada por el servidor, el código de estado o de respuesta y una explicación del codigo

HTTP/1.1 200 OK

Los códigos de estado también son un estándar estipulado en el documento RFC-2616 del protocolo HTTP, algunos de ellos son:

Código = 200

Explicación Breve =  OK

Interpretación del cliente =  Todo está bien; documento encontrados y entregado en la respuesta.

Código = 404

Explicación Breve =  Not Found

Interpretación del cliente =  No se pudo encontrar el recurso en la dirección de la URI especificada en la petición,  ”no such page”.

Código = 405

Explicación  Breve = Method Not Allowed

Interpretación del cliente = El método de la petición (GET, POST, HEAD, DELETE, PUT, TRACE, etc.) no está permitido para el recurso solicitado en la petición.

En el documento rfc-2616 del protocolo HTTP pagina 57 pueden encontrar todos los códigos de estado y su respectiva explicación e interpretación

• Las cabeceras de respuesta, cumplen el mismo propósito que las cabeceras de petición, pero a diferencia de esta las de respuesta notifican al cliente sobre detalles propios de la respuesta y del servidor que la género.

• Contenido del recurso solicitado:  después de las cabeceras de respuesta sigue una línea en blanco que indica el fin de las cabeceras, luego sigue el contenido (la salida) del recurso web solicitado, si es un fichero estático, es decir, su contenido no es procesado por instrucciones programables y ejecutables en el servidor, como por ejemplo PHP, JSP, JSP, Perl, etc, entonces el servidor envía el contenido exactamente como esa dentro del archivo (recurso), si fuera el caso contrario, entonces  el programa adecuado interpreta las instrucciones dentro del recurso y envía la salida (generalmente código HTML + CSS+ JavaScript creado de forma dinámica) al cliente http correspondiente.

Ejemplo de una petición y su respectiva respuesta HTTP para la URL  http://miservidorweb/misitioweb/mipaginaweb.html

Petición del cliente HTTP

Respuesta del servidor HTTP