Comprender cómo se comporta una aplicación cuando recibe peticiones desde un navegador web frente a cuando las recibe desde un cliente API es fundamental para construir servicios robustos. Este repaso consolida los conceptos de versionado, autenticación por token y la correcta configuración de encabezados para que las respuestas del servidor sean coherentes con el tipo de cliente que se conecta.
¿Cómo se configura una petición en Postman para consumir un API?
Postman organiza cada petición en pestañas donde se definen elementos esenciales [0:14]:
- Método HTTP: se selecciona el verbo adecuado (GET, POST, PUT, etc.).
- URL: la dirección del recurso al que se desea acceder.
- Body: cuando se envía un formulario o datos, se utiliza esta pestaña para incluir los campos necesarios.
Al enviar datos de autenticación, por ejemplo, el servidor valida las credenciales y, si son correctas, retorna un token. Este token es en realidad la combinación del ID del usuario con el valor del token generado por el componente instalado en el proyecto [0:38]. Ese token se utiliza después en las siguientes peticiones para demostrar que el usuario ya se autenticó.
¿Por qué es importante el versionado en un API?
El versionado permite mantener compatibilidad hacia atrás mientras se introducen cambios y mejoras [0:55]. La lógica es directa:
- La versión uno soporta a los usuarios actuales y sigue funcionando sin modificaciones.
- Cuando surge la necesidad de crear nuevas funcionalidades o actualizar la estructura de respuestas, se fabrica la versión dos.
- Los usuarios que no deseen actualizar su aplicación continúan consumiendo la versión anterior sin interrupciones.
De esta forma, ambas versiones coexisten y cada cliente decide cuál utilizar según sus necesidades. Esto es especialmente útil en entornos de producción donde forzar una actualización podría romper integraciones existentes.
¿Qué ocurre al conectarse sin autenticación ni encabezados correctos?
Uno de los errores más comunes al probar un API es no incluir el encabezado adecuado que indique el formato de la petición [1:25]. Cuando se intenta acceder a un endpoint protegido sin autenticación desde Postman, el servidor puede interpretar que la conexión proviene de un sitio web y redirige hacia una vista de login HTML.
¿Cómo reproduce este comportamiento el navegador?
Si se copia la misma URL y se pega directamente en el navegador, el resultado es un error de acceso web [1:42]. Esto sucede porque el navegador no envía los encabezados que el API necesita para responder en formato JSON.
¿Cuál es la solución para obtener respuestas JSON?
La clave está en configurar el encabezado Accept con el valor application/json [1:55]. Al hacerlo, se le indica al servidor que la aplicación trabaja con JSON y espera respuestas en ese formato. Con este encabezado presente, el API responde correctamente en lugar de intentar redirigir a una página web.
En resumen, estos son los puntos que conviene tener presentes:
- Acceso web vs. acceso API: son flujos distintos y requieren configuraciones diferentes.
- Versión uno vs. versión dos: el versionado garantiza que los cambios no rompan integraciones previas.
- Sistema de autenticación: si se implementa login, es necesario crear código personalizado para gestionar tokens y validaciones.
Pon en práctica cada una de estas pruebas para verificar los resultados por tu cuenta y comparte cualquier duda que te surja durante el proceso.
