Cuando una petición falla y no sabes por qué
La mayoría de los «la API está rota» son una petición que nunca dijo quién era. La respuesta suele decirlo, en la parte que nadie lee.
API Post/Get cubre todos los métodos HTTP, organiza peticiones en colecciones y carpetas, gestiona cabeceras y autorización y muestra el cuerpo de la respuesta con resaltado de sintaxis. Los atajos de teclado agilizan el ciclo de repetición en cuanto los conoces.
Lee la respuesta entera, no el estado
El hábito que más tiempo ahorra es abrir el cuerpo de la respuesta cuando falla, en vez de reaccionar al estado en rojo. Las APIs escritas por personas ponen ahí el motivo, y suele ser una frase que cierra la investigación.
Después revisa las cabeceras de ambos lados. Una petición enviada sin Content-Type: application/json es la causa individual más frecuente de un 400 aparentemente inexplicable: el servidor recibió tu JSON como texto plano y no pudo interpretarlo.
Los cuatro que significan algo concreto
- 401 — no te autenticaste. Falta el token, está mal formado o va en la cabecera equivocada.
- 403 — te autenticaste y no tienes permiso. Otro problema, otra solución; deja de reenviar el token.
- 404 — en un endpoint que sabes que existe, suele significar que una variable de ruta se resolvió vacía. Comprueba si
{{user_id}}tiene valor en el entorno seleccionado. - 422 — la petición se entendió y los datos se rechazaron. El cuerpo casi siempre nombra el campo.
Un 500 es el único que de verdad es problema del otro lado, y aun así conviene enviar la misma petición sin los campos opcionales antes de reportarlo.
La autorización, donde se va casi todo el tiempo
Configura la autorización a nivel de carpeta y no por petición. Repetir un bearer en diecinueve peticiones significa actualizar diecinueve cuando rote, y la que se te escape será la que depures veinte minutos.
Y guarda el token en una variable de entorno en vez de escribirlo en la cabecera. Así cambiar de entorno cambia también de identidad, que es lo que querías al cambiar.
Preguntas que la gente hace
Recibo un 400 y la petición parece correcta. ¿Ahora qué?
Comprueba que envías Content-Type: application/json. Un cuerpo JSON recibido como texto plano produce exactamente esto: una petición que parece bien y un servidor que no puede interpretarla.
¿Cuál es la diferencia entre 401 y 403?
401 significa que no te autenticaste: token ausente o mal formado. 403 significa que sí y no tienes permiso. Reenviar el token arregla el primero y no hace nada con el segundo.
¿Dónde debe vivir el token de autorización?
En una variable de entorno aplicada a nivel de carpeta. Escribirlo en cada petición implica actualizarlas todas cuando rote, y la que se te escape se convierte en veinte minutos de depuración.
