Bienvenidas a una brevísima historia de qué es la Internet. Me pidieron que trate de contarles en 15 minutos qué es y cómo funciona Internet, o más específicamente la WWW, más conocida como la Web.
La verdad que 15 minutos no es suficiente para tener un sólido entendimiento de todo esto, pero vamos a ver los puntos que más les van a servir mañana y, ojalá, en el comienzo de una nueva carrera como programadora.
Como tengo poco tiempo, hago esto bien rápido: mi nombre es Leandro López, pero en la Internet soy inkel. Trabajo como programador web hace unos 14 años, hoy día para Citrubyste, desde la comodidad del living de mi casa y estoy disponible casi todo el tiempo para consultas. Mi lema es “no hay preguntas tontas, sino tontos que no preguntan”.
A lo largo de la charla muchas veces voy a referirme al cliente, servidor y servicio. El cliente es el navegador, Firefox, Chrome, o Explorer (lo siento mucho). Un servicio es a lo que se conecta el cliente para hacer cosas, como buscar en Google, mandar un mail o subir una foto a Facebook. Por último el servidor es una o varias computadoras, que contienen sitios enteros, y que ejecutan todas las acciones de los usuarios, o sea buscar en la base de datos de Google para mostrar los resultados, procesar una foto subida para luego mostrársela al usuario, etcétera. Muchas veces servidor y servicio se usan sin distinción, ya que un servidor suele estar dedicado nomás a correr un solo servicio.
Lo primero que van a ver es que esta charla va a estar llena de siglas. Como los programadores tenemos miedo que la gente se de cuenta que lo que hacemos no es magia, le ponemos siglas a todas las cosas para confundir. Las que más vamos a usar hoy y mañana son las siguientes:
- URL
- HTTP
- HTML
- CSS
Pero sobran otras tantas que las voy a nombrar rápido en algunos puntos de la charla pero que no son importantes las sepan ya.
La primera, URL, o Localizador Uniforme de Recursos. Básicamente es la dirección de una página en Internet, como por ejemplo:
http://google.com/search?q=railsgirls+buenos+aires
Se divide en varias partes, que son el esquema/servicio (http), dominio (google.com), ruta/path (search), consulta (?railsgirls+buenos+aires) y una cosa que no se ve ahí que de momento no importa.
Todas las direcciones de páginas web son de esta forma, a lo sumo comienzan con https, y no hay otra. Hoy día algunos navegadores no muestran el http o siquiera el https, pero siempre está.
Protocolo de Transmisión de HiperTexto. Mucho ruido para pocas nueces. En pocas palabras define las reglas y la forma de “hablar” para que el cliente y el servidor se comuniquen y se entiendan.
Nació junto con la web, de hecho, la web no existiría sin él. Fue creado por sir Tim Berners-Lee y todos los días deberíamos prenderle una vela en su honor y gracia.
Es lo que se conoce un protocolo de “texto”, que significa que la comunicación entre cliente y servidor es en texto que se puede leer como si fuera un archivo común y corriente (bueno, capaz no es 100% así, pero hay que simplificar).
Lenguaje de Marcado de HiperTexto. Es el formato o lenguaje en el cual se escriben las páginas web. Al servidor en sí le importa poco y nada este formato, pero es lo que el cliente entiende y lo que utiliza para mostrar una página. Hoy día se encuentra en la quinta versión (HTML5), pero en el camino pasaron, bueno, más de 5 capaz.
<doctype !html>
<html>
<head>
<title>RailsGirls Buenos Aires</title>
</head>
<body>
<h1>RailsGirls Buenos Aires</h1>
<p>Gracias por venir.</p>
<p>
<a href="http://railsgirls.com/buenosaires">RailsGirls
Buenos Aires</a>
</p>
</body>
<html>Hojas de Estilo en Cascada (Cascade Style Sheets). Si el nombre no les dice nada, no se preocupen: no le dice nada a nadie. En pocas palabras es una forma de decirle a una página los colores, la tipografía y toda la parte visual, de una manera relativamente sencilla.
body {
font-family: sans-serif;
color: black;
background: #fff;
}
a {
color: lightblue;
}Para poder interactuar con un sitio, lo que el cliente (Firefox, Chrome) hace es pedirle un recurso (página, foto) a un servidor. Normalmente le pide varios al mismo tiempo, pero en todos los casos es igual, así que vamos a ver un ejemplo. Como dijimos antes, el protocolo es muy sencillo, así que vamos a pasar directamente a él.
Lo primero que hace el cliente es conectarse al servidor, normalmente en el puerto 80, que es el puerto por defecto para el servicio de HTTP, y enviarle un verbo seguido de una ruta y un indicador de la versión del protocolo que estamos usando:
GET /hola HTTP/1.0
En este sencillo ejemplo, el verbo es GET, que es el más común de todos los que usuamos a diario: cuando ingresamos una dirección por primera vez, el browser hace un GET, cuando seguimos un link, la mayoría de las veces es un GET, pero hay otros:
- GET
- POST
- PUT
- DELETE
- HEAD
- OPTIONS
- TRACE
- PATCH
(Los últimos tres no los usé nunca, y la mayoría de los browsers solamente implementan los dos primeros, aunque hay trucos para simular la acción de los otros)
Veamos un ejemplo sencillo:
GET /hola HTTP/1.0
echo "GET /hola HTTP/1.0" | nc localhost 8080Esto lo que hace es simular un cliente pidiendo una página que está en /hola, al servidor que está en localhost, o sea mi máquina, al servicio que está escuchando en el puerto 8080. No usé el 80 porque cualquier puerto menor a 1024 necesita permisos especiales, pero no se preocupen por eso ahora.
Esa es la primera mitad de cómo funciona la web. Ahora veamos qué es lo que responde el servidor.
HTTP/1.1 200 OK Content-Type: text/plain; charset=utf-8 Content-Length: 16 Server: WEBrick/1.3.1 (Ruby/2.0.0/2014-02-24) Date: Sat, 12 Jul 2014 13:49:02 GMT Connection: close ¡Hola, Mundo!
Lo primero que vemos es un montón de líneas juntas que siguen un formato ya definido, luego una línea en blanco y finalmente el contenido que va a mostrarse en el navegador.
El primer conjunto de líneas se llaman las cabeceras, y comienza por una primera línea que indica la versión de HTTP utilizado (HTTP/1.1) seguido de un código numérico (200) que indica el resultado del request, y finalmente una oración que explica, humanamente, el resultado.
Hay varios status codes que siguen el siguiente agrupamiento:
| 1xx | Información |
| 2xx | Éxito |
| 3xx | Redirección |
| 4xx | Error del cliente |
| 5xx | Error del servidor |
Los status más comunes son:
| 200 | OK |
| 301 | Movido a otro lugar (permanente) |
| 302 | Movido a otro lugar |
| 404 | No encontrado |
| 500 | Error del servidor |
Esto le sirve al browser para saber qué acción realizar con el cuerpo de la respuesta (si es que hay) y cómo interpretar la respuesta. Por case, en el 200, el servidor procederá a mostrar el contenido del cuerpo de la respuesta, y el formato a utilizar se obtiene en base a las cabeceras. En nuestro ejemplo le dice que el contenido es de tipo texto plano (Content-Type: text/plain) y que el cuerpo tiene 16 caracteres (Content-Length: 16).
Luego de las cabeceras hay una línea en blanco, y finalmente el contenido en sí (¡Hola, Mundo!). El cuerpo de la respuesta, al igual que el cuerpo del request, siempre se separa de las cabeceras con esa línea en blanco.
En principio la cabecera más importante de las respuestas es Content-Type. Ésta le indica al cliente el tipo de la respuesta, y en base a eso se mostrará la página o imagen o interpretará el CSS o lo que deba hacer. Hay cientos de MIME-types (el contenido de Content-Type) y alguno de los más normales son:
| text/plain | Text plano |
| text/html | Página HTML |
| text/css | Archivo CSS |
| image/jpg | Foto |
| image/png | Imagen |
| text/javascript | JavaScript |
Todo muy lindo en el ejemplo anterior, pero la interacción es mínima. Veamos ahora un ejemplo, también mínimo, pero que ilustra el enviar información a un sitio (por ejemplo el contenido de un mensaje de Facebook, o una pavada en Twitter). La respuesta en este caso no cambia mucho, el servidor se comporta casi de la misma manera, lo que sí cambia es la forma de mandar la información.
POST /hola2 HTTP/1.1 Content-Length: 10 Content-Type: application/x-www-form-urlencoded name=inkel
¿Notan algo en particular?
Es muy similar a la respuesta que nos da un servidor, en el sentido que le indica cuán largo es el contenido que se está enviando y el tipo del mismo. El tipo es… críptico por decir lo menos, y no vale la pena meterse muy de lleno en él, pero básicamente lo que le dice es que va en un formato en especial en el cual algunos caracteres se codifican con un formato particular, para poder procesarlos en la aplicación y luego poder verlos y usarlos.
Luego el resto es exactamente igual al primer ejemplo, con los mismos tipos de respuesta y contenidos.
Y eso sería básicamente todo lo que se necesita saber para entender, al menos un poco, la magia que se produce cuando usamos la web.
Vimos qué es un cliente, servidor, servicio y cómo las cosas se comunican unas entre otras para hacer, es verdad, algo extremadamente básico, pero el objetivo es que, incluso aún cuando no hayan entendido todo al ciento por ciento (lo cual es mi culpa y de ninguna manera de ustedes), noten que no es necesario ser ingeniero de la NASA para empezar a adentrarse en este hermoso mundo que es la programación web.