Available inSpanishEnglishFrenchGermanHindiPortugueseRussian
HTTP y REST para entrevistas de backend
Explica por qué un código de estado, una cabecera o un flag de cookie se comporta así, y lee un intercambio roto hasta encontrar la falla. Para desarrolladores backend que ya han publicado APIs REST y nunca han tenido que explicarlas en voz alta. Ochenta y ocho tarjetas siguen una sola petición: el mensaje, los métodos, los códigos de estado, el caching, las cookies y CORS, los trade-offs de REST, HTTP/2 y HTTP/3, y los tokens de sesión; las clases de vulnerabilidades quedan para la deck de OWASP.
La casilla B es el único campo de cabecera que toda petición HTTP/1.1 tiene que llevar. Nómbralo y di qué hace.
Host. Nombra la autoridad a la que va dirigida la petición, de modo que una sola dirección puede servir muchos sitios.
— El destino de la petición no incluye la autoridad: algo tiene que aportarla.
Source
RFC 9110 §7.2: un cliente DEBE enviar el campo Host en una petición HTTP/1.1, y un servidor DEBE rechazar con 400 la que no lo lleve. El alojamiento virtual existe gracias a ese único campo. HTTP/2 y HTTP/3 lo sustituyen por el pseudocampo :authority, que transporta exactamente lo mismo. Una nota de vocabulario para toda la baraja: en español decimos cabecera o encabezado, y petición o solicitud, pero en el cable y en el código el nombre va siempre en inglés. Lo que tecleas aquí es Host.