Cliente-servidor, HTTP y anatomía de una interacción

Antes de empezar#

Cuando escribimos una dirección en el navegador, una aplicación consulta datos o una herramienta descarga un archivo, solemos percibir una acción inmediata. Sin embargo, entre la intención del usuario y el resultado existe una conversación estructurada: alguien formula un mensaje, ese mensaje viaja hasta un sistema remoto, una aplicación decide qué hacer y otro mensaje comunica el resultado.

HTTP proporciona las reglas comunes de esa conversación. Comprenderlas antes de estudiar un framework evita aprender decoradores o funciones como recetas aisladas. El objetivo de esta unidad no es memorizar una lista de términos, sino construir un modelo que permita leer una interacción web y responder cuatro preguntas: quién habla, qué mensaje envía, qué recurso señala y cómo se expresa el resultado.

Conocimientos previos. Solo se presupone familiaridad elemental con valores, funciones, diccionarios y excepciones de Python. No necesitas haber creado una API ni conocer FastAPI.

Mapa conceptual. La unidad sigue este recorrido:

1. Un cliente inicia normalmente la comunicación con un servidor.
2. La intención se expresa mediante una petición HTTP dirigida a un recurso.
3. Una URL ayuda a localizar ese recurso; el método indica la semántica general de la acción.
4. El proceso servidor entrega la petición a una aplicación, que ejecuta su lógica.
5. Una respuesta HTTP comunica el resultado mediante un código, cabeceras y, cuando procede, un cuerpo.

1. Cliente, servidor y ciclo petición-respuesta#

Los dos roles de la conversación#

Un cliente es el participante que formula una petición para obtener o provocar algo. Puede ser un navegador, una aplicación móvil, un programa de línea de comandos, otro servidor o una prueba automatizada. La palabra no describe necesariamente una máquina concreta: describe el papel que desempeña un programa en una interacción.

Un servidor es el participante que escucha peticiones, las interpreta y produce respuestas. También es un rol. Un mismo sistema puede actuar como servidor frente a un navegador y, segundos después, como cliente cuando consulta otro servicio.

En HTTP convencional, el cliente inicia la conversación. Decide a qué dirección se conecta y envía primero la petición. El servidor no llama espontáneamente al navegador para ejecutar una operación ordinaria. Existen mecanismos de comunicación persistente que matizan este modelo, pero se estudiarán más adelante; no son necesarios para comprender el ciclo básico.

No existe una llamada directa entre funciones remotas#

En un programa local, una función puede invocar otra función porque ambas participan en el mismo proceso y comparten memoria. Una interacción web es diferente. El navegador no obtiene una referencia a una función Python que vive en otro ordenador. Construye bytes según un protocolo, los envía por la red y espera otros bytes como respuesta.

En el extremo remoto, el proceso servidor interpreta el mensaje. Después, la aplicación decide qué lógica ejecutar. El vínculo entre la petición y una función es una decisión interna del servidor y de la aplicación; no es una llamada directa hecha por el cliente.

Esta distinción importa por tres razones:

• La red puede fallar antes, durante o después del procesamiento.
• Cliente y servidor pueden estar implementados con lenguajes y tecnologías completamente distintos.
• El único contrato compartido visible entre ambos es el mensaje y su semántica, no la estructura interna del código.

HTTP como protocolo de aplicación#

Un protocolo es un conjunto de reglas que permite a participantes independientes interpretar una comunicación del mismo modo. HTTP define, entre otras cosas, la forma conceptual de peticiones y respuestas, los métodos, las cabeceras y los códigos de estado.

Se denomina protocolo de capa de aplicación porque describe la conversación relevante para los programas que usan la Web. Por debajo existen mecanismos de transporte, direccionamiento y transmisión. Son importantes para que los datos viajen, pero esta unidad se concentra en la semántica HTTP: qué significa el mensaje una vez que llega.

HTTP no exige que cliente y servidor compartan lenguaje, sistema operativo ni framework. Un cliente escrito en JavaScript puede comunicarse con una aplicación Python porque ambos respetan las mismas reglas del protocolo.

Flujo completo y puntos de fallo#

El ciclo esencial puede expresarse como petición → procesamiento → respuesta. En una aplicación real conviene distinguir algunos pasos intermedios:

1. El cliente construye la URL y el mensaje.
2. Se establece o reutiliza una comunicación con el servidor.
3. El proceso servidor recibe y analiza la petición.
4. El servidor determina qué parte de la aplicación debe atenderla.
5. La aplicación valida datos, consulta recursos y ejecuta reglas.
6. La aplicación devuelve un resultado o produce un error.
7. El servidor forma una respuesta HTTP.
8. El cliente interpreta código, cabeceras y cuerpo.

Cada frontera puede fallar de una manera distinta. La dirección podría no resolverse, la conexión podría interrumpirse, el mensaje podría ser inválido, el recurso podría no existir, la aplicación podría rechazar la operación o una dependencia interna podría fallar. Por eso «no recibí el resultado esperado» no identifica todavía la causa.

Máquina, proceso, aplicación y recurso#

La palabra «servidor» se usa de forma ambigua. Para razonar con precisión conviene separar cuatro conceptos:

• Máquina servidor: el ordenador físico o virtual donde se ejecutan programas. Puede alojar muchos procesos.
• Proceso servidor: el programa en ejecución que escucha conexiones y habla HTTP. Puede haber varias instancias del mismo programa.
• Aplicación: el código que interpreta una petición ya encaminada y decide el resultado. Contiene operaciones y reglas propias del sistema.
• Recurso: aquello sobre lo que habla la interacción: un documento, una cuenta, una tarea, una colección o cualquier concepto identificable desde el contrato HTTP.

No siempre existe una correspondencia uno a uno. Una máquina puede ejecutar varios procesos; varios procesos pueden servir la misma aplicación; una aplicación puede exponer muchos recursos. Además, un balanceador u otro intermediario puede hacer que un conjunto de máquinas parezca un único servidor ante el cliente. MDN distingue expresamente entre servidor visible, máquina e instancias de software.

Qué significa que HTTP sea stateless#

Decir que HTTP es stateless significa que, por sí misma, una petición no queda vinculada automáticamente con la petición anterior. Cada mensaje debe aportar la información necesaria para que el servidor pueda interpretarlo dentro del protocolo y del contrato acordado.

No significa que la aplicación no pueda conservar datos. Una base de datos puede guardar cuentas, documentos o pedidos. Tampoco significa que no puedan existir sesiones: cookies, tokens u otros mecanismos permiten relacionar peticiones con un contexto. La idea exacta es que HTTP no crea ni mantiene ese vínculo de forma automática. La aplicación debe diseñarlo explícitamente.

Imagina dos peticiones consecutivas al mismo recurso. Aunque viajen por la misma conexión, HTTP no obliga a la segunda a «recordar» variables locales creadas durante la primera. Si la aplicación necesita reconocer al mismo usuario, debe recibir alguna evidencia o identificador y consultar el estado correspondiente.

2. URL y localización de recursos#

Una URL proporciona la dirección con la que el cliente localiza un recurso y construye la petición. Observemos esta dirección:

https://biblioteca.example:8443/libros/42?idioma=es&formato=resumen#citas

El esquema no es un adorno: selecciona las reglas de acceso. El host conduce hacia la máquina o conjunto de máquinas. El puerto identifica un servicio de red; cuando se usa el puerto predeterminado del esquema suele omitirse de la URL visible. El path localiza el recurso dentro del espacio de nombres del servidor. La query string comienza después de ? y contiene pares separados por &. El fragmento empieza con # y pertenece al cliente.

Rutas estáticas y segmentos variables#

Una ruta como /libros/recomendados contiene segmentos estáticos: el texto tiene el mismo valor para todos los clientes. En /libros/42, el segmento 42 puede representar el identificador de un libro. Al describir el patrón podríamos escribir /libros/{libro_id}; las llaves no forman parte de la petición real, sino que expresan que ese segmento varía.

Un parámetro de ruta forma parte del path y suele participar en la identidad o localización del recurso. Un parámetro de consulta aparece en la query string y normalmente ajusta una selección: filtrar, ordenar, elegir idioma o cambiar una vista. Son tendencias útiles, no una regla mecánica capaz de diseñar por sí sola cualquier sistema.

Codificación básica de URL#

Una URL solo puede representar directamente determinados caracteres. Otros se codifican como un signo % seguido del valor hexadecimal de sus bytes. Por ejemplo, un espacio en una parte codificada puede aparecer como %20; la letra ñ se representa mediante los bytes de UTF-8 codificados.

La codificación evita que un carácter de datos se confunda con un separador estructural. Si un valor contiene &, enviarlo sin codificar dentro de la query podría parecer el comienzo de otro parámetro. Las bibliotecas de cliente deben construir y codificar URLs; concatenar texto manualmente es propenso a errores.

Identificar un recurso no es expresar una operación#

La URL identifica el objetivo; el método HTTP expresa la semántica general de la interacción. GET /libros/42 y DELETE /libros/42 señalan el mismo recurso, pero no solicitan lo mismo. Introducir un verbo dentro de cada path —por ejemplo, /borrar-libro/42— mezcla ambas responsabilidades y puede hacer menos predecible el contrato.

Esta unidad solo establece la separación entre objetivo y operación. El diseño sistemático de recursos y rutas se desarrollará en la Unidad 1.2; todavía no necesitamos convertirlo en reglas de REST.

3. Anatomía de una petición HTTP#

Para estudiar la forma de un mensaje utilizaremos la representación textual de HTTP/1.1. Versiones posteriores pueden codificar y transportar la información de otra manera, pero conservan su semántica esencial.

Una petición contiene:

1. una línea inicial con método, request target y versión;
2. cero o más cabeceras;
3. una línea vacía que separa cabeceras y cuerpo;
4. un cuerpo opcional.

GET /libros/42?idioma=es HTTP/1.1
Host: biblioteca.example
Accept: application/json
X-Request-ID: 8d1f1a4c

La primera línea se lee de izquierda a derecha:

• GET es el método y expresa una operación de lectura.
• /libros/42?idioma=es es el request target: path y query que el servidor debe interpretar.
• HTTP/1.1 indica la versión textual representada.

Después aparecen cabeceras con metadatos. Host identifica el host de destino; Accept comunica que el cliente prefiere una representación JSON; X-Request-ID aporta un identificador de correlación de ejemplo. Tras la última cabecera existe una línea vacía. Como esta petición no lleva cuerpo, el mensaje termina ahí.

POST /notas HTTP/1.1
Host: estudio.example
Content-Type: application/json
Accept: application/json
Content-Length: 74

{
  "titulo": "Resumen de HTTP",
  "contenido": "Petición, respuesta y recurso"
}

Aquí Content-Type: application/json describe el formato del cuerpo que el cliente está enviando. Accept: application/json expresa qué formato de respuesta desea recibir. No son equivalentes: Content-Type describe lo que acompaña al mensaje; Accept expresa una preferencia sobre lo que se quiere recibir.

La línea vacía entre Content-Length y { no es decoración. Marca el final de las cabeceras. El bloque JSON posterior es el cuerpo. En una captura real, la longitud y otros detalles pueden ser calculados por la biblioteca del cliente.

Metadatos y representación#

Un recurso no viaja necesariamente como el objeto interno que usa la aplicación. Viaja una representación: bytes cuyo significado se describe mediante cabeceras y un formato acordado. Un libro podría representarse como JSON, HTML o un archivo, según el contrato y la negociación.

Las cabeceras aportan metadatos sobre esa transferencia. El cuerpo aporta la representación. Esta separación permite que dos cuerpos con bytes distintos describan el mismo recurso, o que el mismo formato se use para recursos diferentes.

El cuerpo no depende de una regla «GET no, POST sí»#

Algunos métodos suelen llevar cuerpo y otros no, pero la realidad no se reduce a una oposición entre GET y POST. La especificación y los intermediarios asignan semánticas diferentes a cada método. Una posibilidad técnica no garantiza que servidores, proxies y clientes interpreten el cuerpo de forma interoperable.

Por eso conviene seguir los usos establecidos: POST, PUT y PATCH suelen transportar una representación de entrada; GET, HEAD, DELETE y OPTIONS normalmente no requieren cuerpo. Cuando un diseño se aparta de esa expectativa necesita una justificación y compatibilidad comprobada.

4. Anatomía de una respuesta HTTP#

La respuesta comienza con una línea de estado. En la forma de HTTP/1.1 contiene la versión, un código numérico y una frase descriptiva. Después aparecen cabeceras, una línea vacía y, cuando corresponde, un cuerpo.

HTTP/1.1 200 OK
Content-Type: application/json
Content-Length: 71
X-Request-ID: 8d1f1a4c

{
  "id": 42,
  "titulo": "Redes para aplicaciones",
  "idioma": "es"
}

HTTP/1.1 indica la versión representada. 200 es el código de estado; OK es una frase legible, pero el código es la parte con semántica normativa. Content-Type describe el cuerpo JSON. El identificador de correlación permite relacionar petición, respuesta y logs cuando ambos extremos lo conservan.

El código y el cuerpo deben ser coherentes. Un 200 OK anuncia éxito; el cuerpo debería representar el resultado de ese éxito, no esconder un error con una propiedad como "success": false.

HTTP/1.1 404 Not Found
Content-Type: application/json
Content-Length: 79

{
  "error": "libro_no_encontrado",
  "mensaje": "No existe el libro 42"
}

El código 404 permite al cliente reconocer la categoría del resultado sin comprender todavía el formato concreto del cuerpo. El cuerpo añade contexto útil para una persona o programa. Un contrato real debería mantener una forma de error estable, pero su diseño se tratará en una unidad posterior.

HTTP/1.1 204 No Content
X-Request-ID: 8d1f1a4c

Una respuesta 204 No Content termina después de las cabeceras: no incluye contenido. Las cabeceras pueden seguir comunicando información. Añadir JSON a una respuesta 204 contradice la semántica del código y puede provocar comportamientos distintos entre clientes. MDN describe 204 como una respuesta sin contenido que todavía puede aportar cabeceras útiles.

Código y contenido cumplen funciones distintas#

El código ofrece una señal general y normalizada. El cuerpo ofrece la representación específica del resultado. Un cliente puede decidir una rama básica con el código —éxito, redirección, error del cliente o error del servidor— y después interpretar el cuerpo según el contrato.

Una respuesta también puede no llegar. Un timeout o una conexión rota no son códigos HTTP, porque no existe un mensaje de respuesta completo. Esta diferencia será importante al diagnosticar integraciones: «el servidor respondió 500» y «no hubo respuesta» son fallos distintos.

5. Métodos HTTP#

El método es un token que expresa la semántica general solicitada sobre el recurso objetivo. No describe toda la lógica de negocio, pero permite a clientes, servidores e intermediarios razonar sobre propiedades como seguridad, idempotencia y caché.

En la terminología normativa, un método es safe si su semántica definida es esencialmente de lectura: el cliente no solicita un cambio de estado. Esto no significa «seguro frente a atacantes» ni prohíbe efectos secundarios incidentales como escribir un log. Un método es idempotent si repetir la misma petición tiene el mismo efecto pretendido en el servidor que ejecutarla una vez. La respuesta puede variar entre intentos. Estas definiciones proceden de RFC 9110, secciones 9.2.1 y 9.2.2.

Safe no significa autenticado ni inocuo en toda circunstancia#

GET es safe porque el cliente solicita leer. Puede requerir autenticación y autorización; la propiedad no dice quién tiene permiso. También puede causar efectos secundarios no solicitados, como registrar una visita o actualizar una métrica. Lo importante es que el cliente no pide un cambio de estado del recurso.

Si una URL como /documentos?accion=borrar&id=17 elimina datos mediante GET, el diseño contradice la semántica safe. Un navegador, crawler o sistema de prefetch podría seguir el enlace esperando una lectura y provocar el cambio. RFC 9110 advierte específicamente contra acciones inseguras escondidas tras métodos safe.

Idempotent no significa «respuesta idéntica»#

Supongamos DELETE /notas/17. La primera petición puede eliminar la nota y responder 204. La segunda puede descubrir que ya no existe y responder 404. Los mensajes son distintos, pero el efecto pretendido tras una o varias peticiones es el mismo: la nota 17 no queda asociada a esa URI.

La idempotencia resulta valiosa cuando el cliente no sabe si el servidor llegó a aplicar la primera petición. Repetir automáticamente una operación requiere más criterio que mirar el método, pero la propiedad ofrece una base semántica para razonar sobre reintentos.

Posibilidad técnica e interoperabilidad#

Un protocolo puede permitir que ciertos bytes aparezcan, pero clientes, intermediarios y servidores necesitan una semántica compartida para utilizarlos. Por eso un cuerpo en GET o DELETE puede ser ignorado, rechazado o tratado de manera distinta. Para un contrato portable, utiliza las ubicaciones que el ecosistema interpreta de forma consistente y documenta cualquier excepción.

6. Códigos de estado#

El código de estado es un número de tres cifras que resume el resultado de la petición desde la perspectiva HTTP. La primera cifra define una familia:

La familia orienta, pero el código concreto aporta la distinción útil. No todos los 4xx significan «JSON mal escrito» ni todos los 5xx son equivalentes. En esta unidad basta dominar un conjunto pequeño y frecuente.

Estas descripciones sintetizan la referencia de códigos de MDN y la semántica de RFC 9110. El código debe elegirse a partir del resultado observable, no a partir de la excepción concreta que utiliza internamente el lenguaje.

401 y 403: identidad frente a permiso#

Aunque el nombre histórico Unauthorized puede resultar confuso, 401 se usa cuando falta una autenticación válida. El servidor normalmente indica cómo autenticarse mediante WWW-Authenticate. 403 se usa cuando el servidor conoce suficientemente la identidad o la situación, pero rechaza el acceso. MDN resume 401 como «unauthenticated» y contrasta 403 con una identidad conocida.

No siempre es conveniente revelar que un recurso existe. Un sistema puede responder 404 en lugar de 403 según una política explícita. Lo importante es mantener una decisión coherente y no confundir autenticación con autorización.

400 y 422: mensaje inválido frente a contenido no procesable#

Una frontera útil —que debe documentarse en cada sistema— es reservar 400 para un mensaje que no puede interpretarse correctamente y 422 para contenido cuyo formato general se reconoce pero que falla semánticamente.

Por ejemplo, un JSON truncado podría producir 400. Un JSON bien formado con un valor que no satisface el contrato podría producir 422. Los frameworks pueden adoptar convenciones más específicas; se estudiarán cuando exista el contexto necesario. Lo esencial ahora es que el cliente pueda distinguir «no pude comprender tu mensaje» de «comprendí su estructura, pero no puedo procesar lo que solicita».

4xx y 5xx no expresan culpa moral#

La clasificación indica dónde debe buscarse la condición que impide el éxito. Un 4xx señala que repetir exactamente la misma petición suele producir el mismo rechazo; el cliente necesita cambiar algo. Un 5xx señala que el servidor no pudo satisfacer una petición que podía ser válida; el cliente no dispone de toda la información para corregirla.

Esto no elimina matices. Una petición puede activar un bug del servidor, o una dependencia remota puede hacer fallar una operación. El código debe representar el contrato que ve el cliente, mientras los logs conservan el diagnóstico interno.

7. Ejemplo integrado#

Un lector quiere consultar la ficha 42 de una biblioteca y solicita la representación en español. Todavía no implementaremos un servidor; seguiremos únicamente la conversación conceptual.

1. El cliente construye la URL. Parte de https://biblioteca.example, añade el path /fichas/42 y la query idioma=es. El fragmento no es necesario porque la petición se dirige al recurso, no a una sección visual de una página.

2. Selecciona el método. Como quiere leer y no solicitar un cambio, usa GET. Esta semántica es safe e idempotent.

3. Añade cabeceras. Declara el host y que prefiere JSON. También envía un identificador de petición para correlación.

GET /fichas/42?idioma=es HTTP/1.1
Host: biblioteca.example
Accept: application/json
X-Request-ID: estudio-0007

4. Envía el mensaje. No añade cuerpo porque toda la información necesaria para esta lectura está en path, query y cabeceras.

5. El proceso servidor recibe la petición. Interpreta la línea inicial y las cabeceras, identifica la aplicación adecuada y localiza la operación que atiende ese patrón.

6. La aplicación procesa el recurso. Convierte 42 en el identificador esperado, busca la ficha y selecciona la representación en español. Si la ficha no existe, produce un resultado de ausencia; si una dependencia falla inesperadamente, produce un fallo interno. Estos son resultados distintos.

7. El servidor forma la respuesta. En el camino satisfactorio elige 200 OK, describe el cuerpo como JSON y conserva el identificador de correlación.

HTTP/1.1 200 OK
Content-Type: application/json
X-Request-ID: estudio-0007

{
  "id": 42,
  "titulo": "Fundamentos de redes",
  "idioma": "es",
  "disponible": true
}

8. El cliente interpreta la respuesta. Primero reconoce el éxito mediante 200. Después utiliza Content-Type para interpretar el cuerpo y presenta los datos. Si hubiera recibido 404, no debería intentar leerlo como una ficha correcta; trataría el contrato de error.

El mismo flujo admite ramas de error:

• Una URL mal construida puede no llegar al proceso correcto.
• Un identificador con formato inválido puede ser rechazado antes de buscar.
• Una ficha ausente puede producir 404.
• Una identidad sin autenticación válida podría producir 401 si el recurso estuviera protegido.
• Un fallo inesperado durante el procesamiento puede producir 500.

La utilidad del modelo está en localizar cada decisión. El cliente decide dirección, método y entrada; el servidor interpreta HTTP; la aplicación decide el resultado; la respuesta vuelve a expresar ese resultado en términos compartidos.

8. Errores conceptuales frecuentes#

9. Síntesis final#

Una interacción HTTP es una conversación entre roles independientes. El cliente inicia normalmente el intercambio y envía una petición dirigida a un recurso. La URL aporta localización; el método expresa la semántica general; cabeceras y cuerpo transportan metadatos y representaciones. El proceso servidor recibe el mensaje, la aplicación decide el resultado y una respuesta comunica ese resultado mediante status, cabeceras y contenido opcional.

HTTP es stateless porque no enlaza automáticamente una petición con la siguiente. La aplicación puede mantener datos y sesiones, pero debe diseñar ese vínculo. Del mismo modo, el cliente no llama directamente a una función remota: ambos extremos cooperan a través de mensajes y un contrato compartido.

Vocabulario esencial:

Después de leer esta unidad deberías ser capaz de explicar el recorrido cliente → servidor → aplicación → respuesta; anotar las partes de una URL; separar línea inicial, cabeceras y cuerpo; clasificar métodos habituales; y elegir entre los códigos estudiados en situaciones sencillas.

Fuentes#

Estos apuntes sintetizan y reorganizan las fuentes siguientes. Las definiciones normativas se han expresado con palabras propias y se han limitado al nivel necesario para la unidad.

• MDN — Overview of HTTP

  Secciones Components of HTTP-based systems, HTTP flow y HTTP Messages: roles, flujo, mensajes, servidor visible y carácter stateless.

• MDN — HTTP response status codes

  Clasificación de familias y significado de 200, 201, 204, 400, 401, 403, 404, 409, 422 y 500.

• RFC 9110 — HTTP Semantics

  Secciones 9.2.1 y 9.2.2 para safe e idempotent; secciones de métodos y status solo como comprobación normativa puntual.

• FastAPI — First Steps

  Secciones Path, Operation, Define a path operation decorator y Return the content como puente terminológico. FastAPI no se desarrolla todavía.