APIs públicas para practicar pruebas de API

Cómo usar esta lista de APIs públicas

Elige una API y una habilidad. Escribe tres casos: el camino feliz, un caso límite y un caso en el que esperas un fallo y compruebas que ese fallo tiene la forma correcta. El tercero es el que casi todo el mundo se salta y el que distingue una suite que encuentra errores de una suite que confirma que el servicio está en línea.

Una nota antes de empezar. Son servicios compartidos que mantienen voluntarios o empresas por cortesía. Mantén un volumen bajo de peticiones, no les apuntes un generador de carga y guarda las respuestas en caché cuando puedas.

Para aprender los fundamentos de peticiones y respuestas

• JSONPlaceholder. Una API REST falsa con posts, comentarios, usuarios y tareas. Acepta escrituras y finge que las guarda. Practica: verbos CRUD, códigos de estado y la diferencia entre una petición que tuvo éxito y un cambio que se persistió. Que las escrituras no se guarden de verdad la convierte en una lección excepcionalmente buena sobre hacer aserciones sobre resultados y no sobre respuestas.

• HTTPBin. Un endpoint que te devuelve como eco lo que le envíes, más rutas que devuelven el código de estado que les pidas, se retrasan a propósito o devuelven payloads malformados. Practica: timeouts, reintentos, manejo de redirecciones y comportamiento de cabeceras. Si quieres ver cómo reacciona tu suite ante un 503, puedes generar uno bajo demanda.

• REST Countries. Datos de países con una estructura estable y bien documentada, y sin necesidad de clave. Practica: aserciones sobre el esquema y validación a nivel de campo en un payload lo bastante grande para ser interesante y lo bastante pequeño para leerlo.

Para paginación y colecciones grandes

Para autenticación y límites de peticiones

Tres aserciones que vale la pena practicar en cualquier API pública

Elijas el servicio que elijas, estos son los hábitos que se trasladan a tu propia API.

• Haz aserciones sobre el cuerpo, no solo sobre el estado. Un 200 que trae una lista vacía donde debería haber un registro es un error que una aserción sobre el código de estado dará por bueno sin dudarlo. Este único hábito detecta más defectos reales que cualquier otro.

• Comprueba que los fallos fallan correctamente. Pide algo que no exista y verifica que recibes el código correcto y un error con una forma utilizable. Los servicios que devuelven 200 con un objeto de error dentro son habituales, y una suite que no lo sepa reportará verde para siempre.

• Haz aserciones sobre las relaciones, no solo sobre los campos. Si un post referencia a un usuario, pide ese usuario y comprueba que existe. Los errores más interesantes viven entre dos endpoints, no dentro de uno.

Apuntar un agente a una de ellas

Si quieres ver cómo es la cobertura generada antes de probarla en tu propio servicio, una API pública es un lugar seguro para hacerlo. No hay datos que contaminar ni entornos que romper.

Apunta un proyecto a la URL base y deja que el descubrimiento enumere los endpoints; después lee el plan generado antes de ejecutar nada. El plan es la parte interesante. Hay dos cosas que conviene observar mientras avanzas.

• ¿Captura los valores en lugar de fijarlos en el código? Una llamada de creación devuelve un identificador y la siguiente llamada debería usarlo. Los identificadores fijados en el código son la razón habitual de que una suite funcione una sola vez.

• ¿Ordena correctamente las llamadas dependientes? No puedes pedir un comentario de un post que nunca se creó. Fíjate en si el plan lo entiende o si simplemente lista los endpoints en orden alfabético.

Después ejecútalo y lee los fallos. En una API pública, la mayoría de los fallos serán tus suposiciones y no el servicio, que es justamente la lección.

Si prefieres ser dueño del código de las pruebas, la CLI toma otro camino para el trabajo de backend: escribes tú mismo las llamadas y las aserciones en Python, declaras qué necesita y qué produce cada prueba, y marcas la limpieza como una prueba aparte. Eso implica más trabajo inicial y deja la suite en tu repositorio, algo que unos equipos quieren y otros no.

Pasar de la práctica a tu propio servicio

La distancia entre practicar con una API pública y probar la tuya es mayor de lo que parece, y saber dónde sube la dificultad te ahorra algo de frustración.

Las APIs públicas no tienen estado desde tu punto de vista: lees, y lo que escribas no se guarda o no importa. Tu propio servicio es lo contrario. En cuanto pruebas algo real heredas autenticación que caduca, registros que tienen que existir antes que otros registros, valores que solo existen en tiempo de ejecución y la obligación de limpiar lo que dejas atrás.

Nada de eso aparece en un tutorial y todo eso aparece en la primera semana. Así que trata la fase de las APIs públicas como el aprendizaje de las aserciones, que se traslada por completo, y asume que el manejo del estado es algo aparte que aprenderás después, no una continuación de la misma habilidad.

Qué no hacer con ellas

• No las uses para pruebas de carga. Son gratuitas, compartidas, y alguien paga la factura.

• No construyas una dependencia de producción sobre una de ellas. Los términos cambian, los proyectos se archivan y los voluntarios se cansan.

• No tomes una suite que pasa contra JSONPlaceholder como prueba de que tu propia API es correcta. Te dice que tu configuración de pruebas funciona, que es una afirmación realmente útil pero mucho más modesta.

Probar esto contra un servicio real

Cuando los hábitos de aserción ya te resultan cómodos, el salto a tu propia API es donde empiezan los problemas de estado, y esa es la parte que TestSprite resuelve como producto. Auto-Authentication mantiene vivas las sesiones durante toda una ejecución. Dynamic Variables lleva un identificador desde la llamada de creación hasta la de borrado. Dependency Chains determina qué tiene que ocurrir primero. Auto-Cleanup elimina lo que la ejecución creó.

Empezar con tu propio servicio se parece al ejercicio con APIs públicas de arriba: apunta un proyecto a la URL base, deja que el descubrimiento enumere los endpoints y lee el plan generado antes de que se ejecute nada. La diferencia es que ahora el plan cubre la autorización y los casos límite, y la ejecución no deja nada atrás.

Es algo seguro de probar primero en una API pública, ya que no hay datos que contaminar, y el plan te dice más sobre la herramienta que los resultados.