400

Bad Request

Cuando el servidor dice "no entiendo qué me estás pidiendo". Validación, sintaxis y errores del cliente.

🤦‍♂️ Client Error

📋 ¿Qué narices es esto?

El código 400 Bad Request es el "no entiendo qué carajo me estás pidiendo" de HTTP. Es la respuesta del servidor cuando tu petición está tan mal formada que ni siquiera puede procesarla. Como cuando le pides a Alexa que "ponga esa canción de ese cantante que hace esa cosa", pero para servidores web. El problema está del lado del cliente, no del servidor.

Este código es la navaja suiza de los errores del cliente. Aparece cuando la sintaxis de la petición es incorrecta, faltan headers obligatorios, el JSON está mal formado, los parámetros son inválidos, o básicamente cualquier cosa que haga que el servidor diga "esto no tiene sentido". Es el equivalente digital de entregar una receta médica escrita con crayones.

El 400 aparece típicamente cuando:

  • JSON mal formado (comas faltantes, llaves desbalanceadas)
  • Headers HTTP inválidos o malformados
  • Parámetros con tipos de datos incorrectos
  • URLs mal codificadas o con caracteres raros
  • Campos obligatorios faltantes en formularios

🎯 Dato curioso

El 400 es un comodín. Muchos servidores lo usan cuando no saben qué error específico devolver. Es como el "no sé, algo está mal" de HTTP. Para casos específicos existen 401, 422, 429, etc.

La frustración del 400 es que es muy genérico. Te dice que algo está mal, pero no necesariamente qué. Los buenos APIs incluyen un mensaje de error descriptivo en el body de la respuesta. Es la diferencia entre "error de sintaxis en línea 1" y "falta una coma después de 'nombre' en tu JSON". Por eso siempre revisa el contenido de la respuesta, no solo el código.

🔧 Cómo manejar esto

🖥️ Para servidores (generar 400s útiles)

  1. Valida entrada temprano: Revisa sintaxis antes de procesar.
  2. Responde 400 + mensaje claro: Explica exactamente qué está mal.
  3. Incluye detalles específicos: Campo problemático, valor esperado.
  4. Usa códigos más específicos: 422 para validación, 415 para content-type.
  5. Logea para debugging: Pero no exposés datos sensibles.

📱 Para desarrolladores frontend

  1. Valida antes de enviar: Revisa JSON, parámetros, headers.
  2. Maneja 400s gracefully: Muestra mensaje de error claro.
  3. Lee el body de respuesta: Ahí están los detalles del error.
  4. Implementa retry inteligente: Solo si el error es transitorio.
  5. Logea para debugging: Pero sanitiza datos sensibles.

Errores típicos que generan 400

  • JSON mal formado:
    {"name": "Juan" "email": "juan@test.com"}
    Falta la coma entre campos
  • Content-Type incorrecto:
    Content-Type: text/plain enviando JSON
    El servidor espera application/json
  • Parámetros inválidos:
    ?age=abc&limit=infinito
    Tipos de datos incorrectos

🚀 Respuesta rápida para emergencias

🔥 Si estás debugging ahora mismo:
1. Revisa el JSON en el body de la respuesta del error
2. Verifica que el Content-Type sea correcto
3. Usa herramientas como Postman para probar manualmente
🎯 Truco ninja:
Muchos 400s son en realidad 422s mal etiquetados. Si la sintaxis está bien pero la validación falla, debería ser 422.