Tema: http
-
Usar correctamente los códigos de estado HTTP: la primera bifurcación del cliente
Los clientes, las cachés y los agentes deciden únicamente a partir del código de estado si reintentar, recargar o desistir: 201/204 para el éxito con y sin cuerpo, 401 frente a 403 para la falta de autenticación frente a la falta de autorización, 409/412/428 para conflictos y condiciones previas, 429 y 503 con Retry-After para «más tarde». Un 200 con un objeto de error engaña a todos.
-
Respetar Retry-After como límite inferior
Programar los reintentos a partir de cualquiera de las dos formas de Retry-After, preservando el plazo de la tarea y evitando solicitudes repetidas prematuras.
-
Retroceder como cliente: Retry-After, las cabeceras RateLimit y presupuestos por host
Cómo debe reaccionar un agente ante respuestas 429 y 503 y ante las cabeceras informativas de límite de tasa: respetar Retry-After al pie de la letra, y si no está presente retroceder de forma exponencial con jitter, leer los campos RateLimit y RateLimit-Policy cuando un servidor los envíe para adelantarse al límite, mantener un presupuesto por host y por clave, y no reintentar nunca una escritura no idempotente sin una clave de idempotencia.
-
Compresión de respuestas: dónde aplicarla y qué excluir
Comprimir las respuestas de texto (HTML, JSON, Markdown) en el proxy o en la aplicación, omitir el contenido ya comprimido y el de streaming, mantener los ETags coherentes entre codificaciones, y establecer Vary: Accept-Encoding.
-
Trazado distribuido en líneas generales: spans, identificadores de padre y W3C Trace Context
Una traza es un árbol de spans, cada uno con un identificador de traza, un identificador de span propio, un identificador de span padre, marcas de tiempo, atributos y un estado; la cabecera W3C traceparent transporta el identificador de traza, el identificador del padre y un indicador sampled entre límites de proceso, y un servicio que se limita a reenviar ambas cabeceras mantiene igualmente unida la traza.
-
Páginas 404 personalizadas y soft 404: servir la página de error con el estado de error
Una página 404 personalizada solo ayuda a quienes la visitan si se sirve con el estado 404; una página de no encontrado servida con 200 es un soft 404 que los rastreadores siguen solicitando y que los buscadores excluyen. El error_page de nginx puede reescribir el estado (error_page 404 =200 ...), que es exactamente cómo se crean los soft 404 por accidente; conviene conservar el estado, hacer útil la página y comprobarlo con curl -I.
-
La política del mismo origen: qué es un origen y qué aísla
Un origen es el esquema, el host y el puerto de una URL. Un script puede leer y modificar documentos, almacenamiento y respuestas del mismo origen; las lecturas entre orígenes se bloquean de forma predeterminada, mientras que las escrituras entre orígenes, como los envíos de formularios, y la incrustación, como imágenes y scripts, suelen estar permitidas. CORS relaja las lecturas; aun así siguen siendo necesarias las defensas contra CSRF.
-
Usar fetch con tiempos de espera y AbortController
Una promesa de fetch se rechaza solo ante un fallo de red, no ante un estado de error HTTP, y no tiene tiempo de espera por sí misma. Pasar una AbortSignal combinada a partir de AbortSignal.timeout y un controller de quien llama, comprobar response.ok, y distinguir en el catch entre TimeoutError, AbortError, errores de red y errores HTTP.
-
Diseñar operaciones idempotentes y reintentos seguros
Una operación es idempotente cuando ejecutarla varias veces tiene el mismo efecto que ejecutarla una sola vez; el RFC 9110 establece esto para los métodos HTTP, y una cabecera Idempotency-Key traslada la propiedad a POST. Guardar la clave junto con una huella y el resultado, informar los conflictos con 409 y 422, y eliminar las claves tras un plazo documentado.
-
Eventos enviados por el servidor frente a WebSockets
Los eventos enviados por el servidor transmiten eventos de texto del servidor al cliente sobre HTTP normal, con reconexión automática e identificadores de último evento; los WebSockets ofrecen un canal bidireccional con capacidad binaria y protocolo propio. Elegir SSE para actualizaciones en un solo sentido y WebSockets cuando el cliente debe enviar con frecuencia.
-
Llamar a la API de TypeSafe desde un agente: forma de la solicitud, errores, reintentos y fijación de versión
El contrato documentado que necesita un agente para llamar a Jev sin una capa de chat: POST /v1/systemone con una clave Bearer, un estado, un nombre de modelo y un mapa de preguntas tipadas; las respuestas se indexan igual que las preguntas, más un bloque de uso; los códigos 401, 422, 429 y 529 con backoff exponencial; alias que cambian de versión frente a identificadores versionados que no cambian; los valores por defecto del SDK para los reintentos y la skill del agente para agentes de codificación.
-
La cabecera Link y los tipos de relación de enlace
El RFC 8288 permite que cualquier respuesta HTTP incluya enlaces tipados en una cabecera Link: <destino>; rel="relación" más los parámetros opcionales anchor, hreflang, type, title y media. Los nombres de relación proceden del registro de la IANA (next, prev, canonical, alternate, describedby, preload) o son URI absolutas para extensiones privadas. Es el modo en que las respuestas no HTML señalan a sus vecinas y en que el código 103 Early Hints indica a un navegador qué obtener por adelantado.
-
Fundamentos de Web Push: suscripciones, claves VAPID y el servicio push
El navegador se suscribe al servicio push de su proveedor y entrega a la página un endpoint más un conjunto de claves; el servidor de la aplicación envía mensajes cifrados a ese endpoint mediante POST con un encabezado TTL y un JWT VAPID (ES256, aud = origen del servicio push, exp de máximo 24 horas) cuya clave pública se pasó a PushManager.subscribe como applicationServerKey. Un 201 significa aceptado, no entregado.
-
Sitemaps y direcciones canónicas: un contenido, una dirección
Cada contenido debería tener exactamente una dirección HTTPS canónica, declarada en la propia página; los duplicados, como las versiones en Markdown o JSON, remiten a ella mediante un encabezado Link, los parámetros sin efecto sobre el contenido no generan direcciones nuevas, y el sitemap lista solo direcciones canónicas con fechas de modificación verídicas.
-
HEAD y OPTIONS: qué responden y para qué los usan los clientes
HEAD es GET sin cuerpo: mismo estado y encabezados (Content-Length y Vary pueden omitirse), almacenable en caché, y se usa para verificar enlaces, sondear el tamaño y comprobar la vigencia. OPTIONS pregunta qué opciones de comunicación admite un recurso o el servidor completo (OPTIONS *), se responde normalmente con Allow, no es almacenable en caché, y transporta los preflight de CORS con Access-Control-Request-Method.
-
Recorrido por un acortador de URL: generación de claves, estado de redirección y controles contra abusos
Un recorrido de diseño para un acortador de URL: claves aleatorias en base62 con reintento ante colisiones, una ruta de redirección que toca una sola caché y un único almacén, 302 en lugar de 301 cuando los destinos deben seguir siendo revocables y contables, comprobaciones contra abusos en la creación, y una lista de lo que no conviene construir primero.
-
Reducir las cadenas de redirección a un único salto aumenta la proporción de solicitudes de rastreadores que terminan en un 200 en un sitio grande
Hipótesis: en un sitio con decenas de miles de URL y redirecciones acumuladas, reescribir cada cadena para que cada URL antigua responda con una única redirección a su destino final aumenta de forma medible la proporción de solicitudes de rastreadores de búsqueda que llegan a una página 200 dentro de un volumen fijo de solicitudes diarias, porque los rastreadores gastan solicitudes en cada salto; se propone una prueba de antes y después sobre los registros del servidor.
-
JSON Web Tokens: qué puede salir mal y las respuestas de RFC 8725
Los JWT son afirmaciones (claims) firmadas, no secretos cifrados; conviene validar el algoritmo contra una lista de permitidos, verificar el emisor, la audiencia y la expiración, mantener vidas cortas, no aceptar nunca 'none', y recordar que un token sin estado no puede revocarse sin una lista en el servidor.
-
Endpoints masivos y el reporte de fallos parciales
Un endpoint masivo tiene éxito o falla como un todo, o bien informa de los resultados por elemento; un único 200 no puede expresar un éxito parcial, por lo que conviene elegir un comportamiento por endpoint, indexar los fallos por posición, limitar el tamaño del lote, y aplicar la autorización y los límites de tasa por elemento.
-
Elegir los códigos de estado HTTP de forma deliberada
Los códigos de estado son lo primero sobre lo que ramifica un cliente: 200/201/204 para el éxito, 304 para lo que no cambió, 400/422 para una entrada incorrecta, 401/403 para credenciales frente a permiso, 404 para lo ausente, 409/412/428 para conflictos y precondiciones, 429/503 para más tarde.
Legible por máquina: JSON