HTTP (Hypertext Transfer Protocol) es un protocolo de comunicación que permite la transferencia de documentos de hipertexto. Es decir, páginas web que utilizan hipervículos para interconectarse. Se trata de un protocolo de la capa de aplicación, base de Internet tal y como lo conocemos.
¿Cómo funciona HTTP?
El uso más común de HTTP es la emisión de una petición desde nuestro dispositivo al servidor, así como la emisión de una respuesta de vuelta desde el servidor a nuestro dispositivo.
Estas peticiones HTTP contienen una serie de metadatos, que incluyen:
- Versión HTTP.
- URL de destino.
- Método HTTP utilizado (method).
- Cabeceras HTTP (headers).
- Opcionalmente, un cuerpo HTTP (body).
Los métodos HTTP
Las peticiones HTTP utilizan un método, que podemos identificar con un verbo que indica una acción. Los dos métodos más frecuentes son:
- GET. Suele utilizarse para obtener recursos del servidor.
- POST. Suele utilizarse para enviar recursos al servidor.
Por ejemplo, cuando visitamos una página web estamos haciendo una petición GET a la URL donde se encuentra. Este es el método por defecto de nuestros navegadores.
A su vez, si queremos enviar un formulario a ese servidor (por ejemplo, para contactar con su administrador) lo haremos mediante una petición POST (generalmente).
También existen otros métodos HTTP:
- HEAD. Como GET, solicita una respuesta con información, pero sin el cuerpo de la respuesta.
- PUT. Como POST, envía información al servidor, pero su objetivo no es introducir nuevos datos, sino sustituir los existentes.
- PATCH. Como PUT, envía información al servidor para modificar los datos existentes, pero en este caso solo de forma parcial.
- DELETE. Solicita la eliminación de recursos.
- CONNECT. Establece un túnel hasta el recurso seleccionado, iniciando una comunicación bidireccional (por ejemplo, al establecer una conexión FTP).
- OPTIONS. Describe las opciones de comunicación con el recurso objetivo.
- TRACE. Comprueba la ruta hasta el recurso de destino.
Las cabeceras HTTP
Una petición HTTP incluye una serie de metadatos almacenados como pares de clave-valor en su cabecera. La información contenida en las cabeceras HTTP se utiliza para describir la comunicación, así como para gestionar servicios adicionales como la seguridad de la petición.
Los cuerpos HTTP
Decimos que las cabeceras de una petición HTTP son metadatos porque definen las reglas y detalle de la misma. Por tanto, se utilizan “a nivel interno” por el cliente y el servidor. Sin embargo, no contienen la información que resulta útil al usuario (como una imagen o una página web).
Esta información orientada al usuario se contiene en el cuerpo de la petición o respuesta. Por ejemplo, cuando iniciamos sesión en un sitio web, enviamos una petición HTTP en cuyo cuerpo se incluyen nuestra contraseña y nombre de usuario (o email). El servidor utilizará esta información para contrastarla con la base de datos, decidir si somos un usuario legítimo y, en caso afirmativo, aceptar la conexión (por ejemplo, mandándonos una cookie o token de autenticación).
A su vez, si estamos visitando una página web, el servidor nos mandará el HTML solicitado en el cuerpo de su respuesta.
Diferencias entre cabeceras y cuerpos HTTP
En resumen, toda petición y respuesta HTTP contiene una cabecera que define la interacción, y que no tenemos que configurar. Serán el propio navegador y el servidor quienes la gestionen por nosotros.
Opcionalmente, la petición o respuesta puede contener un cuerpo. En este viajará información útil. Así, en las peticiones se contendrá la información que queremos transmitir al servidor (comúnmente conocida como payload), y en las respuestas se incluirá el recurso que hemos solicitado al servidor.
Peticiones y respuestas
No debemos olvidar que HTTP es un protocolo de comunicación. Por tanto, su función es estructurar el mensaje de modo que ambas partes puedan entenderse.
En este sentido, llamamos petición al mensaje que envía el cliente a un servidor. Y llamamos respuesta al mensaje que el servidor devuelve en respuesta.
¿Tienen la misma estructura las peticiones y respuestas?
No. Aunque las cabeceras y cuerpos son conceptos comunes, las peticiones, como hemos visto, llevan un método. Es decir, el verbo que indica qué queremos hacer en el servidor (por ejemplo, DELETE si queremos borrar un post de nuestro blog).
Así, no tiene sentido que la respuesta incorpore un método. Y por eso, en lugar de métodos, las respuestas llevan un código de estado HTTP (HTTP status code).
Los códigos de estado HTTP
Un código de estado HTTP está compuesto por 3 dígitos, que indican qué ha ocurrido en el servidor una vez recibida la petición. Estos códigos se agrupan en cinco tipologías, siendo el primer dígito el que indica el resultado de la petición:
- 1xx. Indica que la respuesta contiene información sobre la transacción.
- 2xx. Indica que la petición ha tenido éxito.
- 3xx. Indica que el servidor ha redirigido la petición.
- 4xx. Indica que ha habido un error del cual es responsable el cliente.
- 5xx. Indica que ha habido un error del cual es responsable el servidor.
Todo usuario ha visto en alguna ocasión un “error 404” (recurso no encontrado) o un “error 500” (error en el servidor).
Los códigos de estado HTTP nos permiten:
- Saber si nuestra petición ha tenido éxito o no y por qué.
- Como desarrolladores, diseñar soluciones para los casos de error. Por ejemplo, si pedimos un recurso y obtenemos un error 404 sabemos que la URL es incorrecta, y podemos indicárselo al usuario.
¿Qué códigos de estado existen?
A continuación recojo los códigos de estado con los que podemos encontrarnos. Puedes visitar la web de MDN para más información sobre cada uno de ellos.
Respuestas informativas más frecuentes
| Código | Significado |
| 100 | Continue. El cliente debe continuar la petición. |
| 101 | Switching Protocols. El servidor está cambiando de protocolo. |
| 102 | Processing. El servidor ha recibido la petición y está procesándola, pero todavía no tiene una respuesta. |
| 103 | Early Hints. El cliente puede empezar a precargar recursos mientras el servidor termina de preparar la respuesta. |
Respuestas de éxito más frecuentes
| Código | Significado |
| 200 | OK. La petición ha sido exitosa y se ha cumplido la acción determinada por el verbo (método HTTP). |
| 201 | Created. Se ha creado el recurso solicitado por una petición POST o PUT. |
| 202 | Accepted. Se ha recibido la respuesta, peor todavía no se ha ejecutado la lógica de la aplicación |
| 203 | Non-Authoritative Information. La petición ha tenido éxito, pero se ofrecen metadatos recolectados de terceros, en lugar de del propio servidor. |
| 204 | No content. La petición ha tenido éxito, pero no hay contenido para la respuesta (aunque tal vez las cabeceras sean útiles). |
Respuestas de redirección más frecuentes
| Código | Significado |
| 300 | Multiple choices. Hay más de una respuesta posible para la petición, por lo que el cliente debería elegir una de ellas. |
| 301 | Moved permanently. El recurso se ha movido permanentemente, por lo que se envía la nueva URL. |
| 302 | Found. El recurso se ha movido temporalmente, así que se debe redirigir a una nueva URL, pero en el futuro se podrá volver a utilizar esta. |
| 304 | Not modified. El recurso no se ha modificado, por lo que el cliente puede utilizar la versión cacheada. |
| 307 | Temporary redirect. Como en el caso del 302, el recurso ha sido movido temporalmente. Pero en este caso se repite el verbo HTTP. Es decir, con un 302 se envía un GET a la nueva URL. Con un 307 se envía el verbo utilizado a la nueva URL. |
| 308 | Permanent redirect. Como un 301, indica una redirección permanente. Y como 307, la realiza conservando el verbo HTTP empleado en la petición original. |
Respuestas de error del cliente más frecuentes
| Código | Significado |
| 400 | Bad request. El servidor no procesará la petición debido a algún error detectado en el cliente. |
| 401 | Unauthorized. El cliente debe autenticarse para acceder al recurso. |
| 403 | Forbidden. El cliente, aunque esté autenticado, no tiene permisos para acceder al recurso. |
| 404 | Not found. El servidor no puede encontrar el recurso solicitado. |
| 405 | Method not allowed. No se permite el uso de ese método HTTP en esa ruta. |
| 408 | Request timeout. El servidor quiere cerrar la conexión porque ha pasado mucho tiempo sin utilizarse. |
| 409 | Conflict. La petición enviada presenta conflictos con el estado actual del servidor. |
Respuestas de error del servidor más frecuentes
| Código | Significado |
| 500 | Internal server error. El servidor no procesará la petición porque ha encontrado una situación que no sabe cómo gestionar. Se trata de un código de error que solemos utilizar por defecto, cuando no tenemos otro código más apropiado. |
| 501 | Not implemented. El método empleado no ha sido implementado, por lo que no puede gestionarse. Ten en cuenta que el servidor solo está “obligado” a soportar los métodos GET y POST. |
| 502 | Bad gateway. El servidor estaba actuando como un puente y ha recibido una respuesta de error del destino final. |
| 503 | Service unavailable. El servidor no está preparado para gestionar la petición. Generalmente, porque está saturado o caído. Tratándose de un estado temporal, la respuesta no debería cachearse. Además, se puede enviar una cabecera Retry-After para que el cliente repita la petición pasado cierto tiempo. |
| 504 | Gateway timeout. El servidor está actuando como puente y no ha recibido una respuesta a tiempo. |
Resumen: ¿Qué es HTTP?
En resumen, HTTP es un protocolo de comunicación entre máquinas, basado en el intercambio de hipertexto o enlaces entre documentos. Les permite enviar peticiones y respuestas, estructurando la información de tal modo que resulte fácilmente interpretable.
En concreto, las peticiones HTTP incluyen:
- Una URL, que señala el recurso al que intentan acceder.
- Un método, que indica qué pretenden hacer con ese recurso.
- Cabeceras, que aportan información útil sobre la petición y sirven a cliente y servidor para gestionar la respuesta.
- Opcionalmente, un cuerpo, a través del cual se puede especificar la información a obtener, registrar, editar…
Recibida la petición HTTP, el servidor devolverá una respuesta, que incluirá:
- Un código de estado, que indicará si se ha podido gestionar la petición y, en su caso, información adicional como el estado de la misma o las razones del error.
- Cabeceras y cuerpo, que funcionan del mismo modo que en las peticiones.
¿Cómo nos afectan estos elementos como desarrolladores?
Frontend
Como desarrolladores frontend, debemos conocer el estándar HTTP:
- Del método empleado en nuestras peticiones dependerá la acción que estemos solicitando del servidor. Particularmente en el caso de API REST. Además, debemos saber que no todos los métodos tienen los mismos elementos. Por ejemplo, no tiene sentido que un método GET tenga cuerpo, que a su vez es virtualmente imprescindible en las peticiones POST o PATCH.
- Debemos configurar las cabeceras de nuestras peticiones para que el servidor entienda qué necesitamos de él. Por ejemplo, indicando el formato en que enviamos nuestros datos mediante una cabecera Content-Type.
- Tenemos que configurar adecuadamente nuestro payload, o el cuerpo de la petición, para que se corresponda con la estructura esperada por el servidor y este pueda gestionarla.
- Al recibir la respuesta, debemos estar atentos al código de estado, por si ha habido errores y tenemos que dar feedback al usuario.
- Además, tendremos que gestionar el cuerpo de la respuesta. Si este es HTML, lo más normal será que se renderice automáticamente. Pero si recibiéramos otro tipo de información, como un JSON, es posible que tengamos que mapearlo para obtener las piezas de información que nos resulten útiles y adaptarlo a nuestra interfaz.
Backend
Al desarrollar en el lado del servidor, es igualmente importante que sepamos cómo funciona HTTP:
- Tenemos que saber interpretar las cabeceras y cuerpos que nos envía el frontend para aplicarles una lógica.
- Estas cabeceras y cuerpos nos llevarán a cribar las peticiones. Por ejemplo, desestimando las que no estén autorizadas, no tengan un formato comprensible por el servidor o soliciten recursos inexistentes.
- Lo cual nos llevará a configurar los diferentes códigos de estado, que debemos devolver en todo caso al cliente para que sepa qué ha pasado con su petición.
- Además, cuando haya que devolver un cuerpo en la respuesta, somos los encargados de configurarlo adecuadamente.