7.2.1.1. Términos

Antes de meternos en harina, es conveniente aclarar algunos términos relativos al servicio web:

HTTP

Es la denominación del protocolo ideado originariamente por Tim Berners-Lee. Dedicaremos parte del estudio a analizarlo.

HTTPs

Es, simplemente, el protocolo anterior cifrando mediante SSL (o TLS, según se prefiera denominar). Para más información sobre cómo actúa este cifrado puede consultar las explicaciones contenidas en el apéndice sobre Criptografía.

Navegador

Es la aplicación que habitualmente se usa como cliente en el protocolo HTTP. Huelga presentarla porque es seguro que el lector la utiliza constantemente.

Recurso web

Es cualquier archivo facilitado a sus clientes por el servidor web (página web, imagen, sonido, audio, etc.). Simplificando mucho, podemos considerar un servidor web como un servidor que permite a sus clientes (los navegadores) descargar archivos junto a información adicional sobre como interpretarlos, a fin de que éstos la presenten de modo adecuado al usuario. Así pues, si ante una petición del navegador el servidor devuelve un archivo de audio (un mp3, por ejemplo), además de devolverlo le indicará al navegador de qué naturaleza (¡oye! esto es un archivo audio/mpeg[1]) para que el navegador, si le es posible, lo reproduzca como tal.

HTML

Es el lenguaje de marcas en el que se escriben las página web. Su versión actual es la 5 y es un estándar vivo[2]. No entra dentro de este manual tratarlo ni es necesario conocerlo para configurar el servicio web más allá de improvisar alguna página sencilla de prueba.

CSS

Es el lenguaje en el que se describe el aspecto de las páginas web. Este aspecto suele escribirse en archivos independientes al HTML con extensión .css. Tampoco requerimos su conocimiento.

Javascript

Es el lenguaje de programación que utilizan los navegadores para ejecutar el código con el que se manipula la información recibida. Este código es suministrado por el servidor junto al HTML, el CSS y otros recursos adicionales como imágenes. Originariamente nació para crear efectos extra en las páginas (habitualmente prescindibles), pero su uso actual es bastante distinto. En muchos casos, el servidor web se limita a proporcionar una estructura de página web (un archivo HTML muy básico), un aspecto (un archivo CSS), un código Javascript y unos datos crudos (un JSON, por ejemplo), y es el propio navegador ejecutando el código asociado el que crea la página HTML final. Esto permite delegar parte del trabajo en el cliente y, en consecuencia, liberar de trabajo al servidor.

A efectos de lo que tratamos aquí, los archivos Javascript son simplemente otro recurso web que el servidor facilita al cliente, puesto que su ejecución se lleva a cabo toda en el navegador.

Aplicación web

Es un programa que se ejecuta en el servidor con el objeto de generar bajo demanda contenidos dinámicos que el servidor ofrece a los navegadores.

Entendamos el concepto. Imaginemos que creamos una página web con cuatro recetas de cocina. Como son sólo cuatro, podemos hacer una única página HTML que contenga las cuatro, una debajo de la otra y al comienzo un pequeño índice que nos lleve con hiperenlaces directamente a cada una de ellas. Habrá por supuesto imágenes (archivos de imagen adicionales) y, como queremos hacerla atractiva, algún archivo CSS. Pero todo ello son archivos estáticos, esto es, archivos almacenados en el servidor que el servidor entrega al navegador cuando este los pide.

Ahora bien, imaginemos que tenemos miles y miles de recetas bien organizadas y estructuradas en una base de datos, y nuestra intención es hacer un sitio web que permita a nuestros visitantes buscar recetas en ella. En ese caso, la solución anterior no nos sirve ya que, dependiendo de la búsqueda que haga, deberá obtener unas u otras recetas. Como a priori no sabemos qué términos usará en sus búsquedas, no podemos crear de antemano las páginas web, sino que estas tienen que generarse bajo demanda según se realizan las búsquedas. En este caso, por tanto, necesitamos que el servidor tome los términos de la búsqueda y, con un código de programación, los procese para llevar a cabo la consulta en la base de datos y genere la correspondiente página web dinámica. He aquí una aplicación web.

La aplicación web sí se ejecuta en el servidor y nuestro trabajo como administradores, aunque no consista en desarrollarla, sí requiere permitir su ejecución en el servidor y devolver sus resultados al cliente.

URI, URN y URL

Una de las grandes aportaciones de Tim Berners-Lee es el concepto de URI, que es simplmente un identificador que permite declarar inequívocamente cualquier recurso de internet. Por ejemplo, la dirección de correo bartolo@mail1.org, es una URI, puesto que es única: no hay ningún otro recurso en internet que identifiquemos con ella. Como vemos estos no está asosciados únicamente al protocolo HTTP.

Ahora bien, existen dos maneras de identificar un recurso: por su nombre, URN, o por su ubicación, URL. Digamos que, si estuviésemos hablando de personas, la URN sería su nombre y la URL, su domicilio. Obviamente hay una diferencia: puede haber dos personas con idéntico nombre o con idéntico domicilio (los miembros de una familia), en cambio en lo referente a recursos, nombre y dirección debe ser únicos. Por este último motivo, si un recurso tiene ubicación, al ser única, la propia ubicación sirve para identificarlo.

Centrómonos en la URL. En ella se distinguen tres partes:

esquema://dirección
Esquema

Identifica el tipo de recurso. Por lo general, adopta el nombre del protocolo usado para la obtención del recurso: http, ftp, etc.

Dirección

Fijado el esquema, Indica exactamente cómo y dónde alcanzar el recurso. Su forma es variable, pero por lo general se descompone en dos partes:

máquina/ruta
Máquina

Es el nombre único del equipo en que se encuentra el recurso. Sin embargo, puede contener más información que sólo el nombre:

maquina = [usuario[:contraseña]@]nombre[:puerto]

es decir, si el acceso requiere autenticación también puede incluir un nombre de usuario y contraseña. Además también es posible indicar un puerto de conexión cuando este no es el predeterminado.

Ruta

Siga la notación de rutas en UNIX, es decir, /images/diagrama.png, significa que el recurso es la imagen diagrama.png que se encuentra dentro del directorio images, que a su vez es un subdirectorio el directorio raíz. Entiéndase que este directorio raíz, es el directorio raíz para el servidor web, no para el sistema de ficheros.

Nota

En el protocolo HTTP a la ruta puede añadirse una almohadilla seguida de un identificador. Por ejemplo:

http://www.example.net/documento.html#seccion1

En este caso, la almohadilla y el identificador no modifican la ruta, sino que sirven para indicar un enlace interno dentro del documento, que permite al navegador posicionarse allí donde se haya definido el identificador. Desde el punto de vista del servidor esto, por lo general, es absolutamente indiferente.

Nota

También en HTTP puede añadirse un signo de interrogación, seguido de pares clave=valor separadas por el signo &. Por ejemplo:

http://www.example.net/index.php?nombre=Juan&edad=42

De nuevo en este caso, la interrogación y los pares no forman parte de la ruta y sirven para enviar datos al servidor para que una aplicación los procese.

Notas al pie