Qué es una API

Una API es la forma en que un programa le pide algo a otro programa. El nombre viene de application programming interface (interfaz de programación de aplicaciones), lo que dice muy poco. En la práctica, y en el resto de este tutorial, una API es un servidor que responde a peticiones con datos en lugar de con páginas web.

Una app del tiempo en tu móvil no guarda las previsiones. Cuando la abres, envía una petición a un servidor en algún lugar, recibe unos pocos kilobytes de temperaturas y velocidades del viento, y los dibuja en la pantalla. La parte del servidor es la API. La app es uno de sus clientes.

Tu primera petición

Pega esta dirección en la barra de direcciones del navegador y pulsa Intro:

https://api.testingapis.com/api/Products/1

Recibes algo parecido a esto:

{
  "id": 1,
  "title": "Wireless Noise-Cancelling Headphones",
  "price": 249.99,
  "description": "Over-ear headphones with 30hr battery life and active noise cancellation.",
  "category": "electronics",
  "image": "https://picsum.photos/seed/prod1/400/400",
  "rating": { "rate": 4.3, "count": 127 },
  "inStock": true,
  "createdAt": "2025-06-12T10:30:00Z"
}

Tu navegador envió una petición a un servidor. El servidor buscó el producto número 1 y devolvió su descripción. Ese intercambio, una petición y una respuesta, es a lo que se reduce toda interacción con una API. El resto de este tutorial trata de los detalles de ese intercambio y de cómo comprobar que el servidor los hace bien.

También puedes enviar la petición desde esta página. El botón Enviar de abajo hace lo mismo que acaba de hacer tu navegador y muestra el estado de la respuesta encima del cuerpo. Verás estos botones a lo largo de las lecciones.

Clientes y servidores

El programa que envía la petición es el cliente. El programa que responde es el servidor. Un cliente puede ser un navegador, una app del móvil, otro servidor, una herramienta de línea de comandos o un test que has escrito. El servidor no los distingue, ni lo necesita. Lee la petición, hace su trabajo y responde.

Esto importa para el testing. Como el servidor trata igual a todos los clientes, puedes probarlo sin la app que normalmente habla con él. No necesitas recorrer cinco pantallas de una app de compras para ver si el precio de un producto es correcto. Le pides el producto a la API y miras el precio.

Endpoints

La dirección que abriste tiene dos partes. https://api.testingapis.com es la URL base: dice con qué servidor hablar. /api/Products/1 es la ruta: dice qué quieres de ese servidor. Cada ruta que entiende el servidor se llama endpoint. Esta API tiene unos cuantos cientos. Algunos ejemplos:

Qué endpoints existen lo averiguas en la documentación de la API. Para esta API es la referencia de la API. En los proyectos reales esto varía mucho. Algunos tienen una documentación cuidada, otros un archivo OpenAPI generado a partir del código, y otros un mensaje en un canal de chat del desarrollador que la escribió. Parte del trabajo de quien prueba es darse cuenta de cuándo la documentación y la API no coinciden.

Cuando la respuesta es no

Ahora pide un producto que no existe:

El servidor responde:

{
  "status": 404,
  "error": "Not Found",
  "message": "Product with ID 9999 does not exist."
}

Esta también es una respuesta correcta. No existe el producto 9999, y el servidor lo dice con claridad: un estado 404, que significa "no encontrado", y un mensaje que explica qué ID faltaba. Una buena API cuida tanto las peticiones que no puede atender como las que sí. Buena parte del testing de API ocurre aquí, en el camino infeliz, porque es donde los desarrolladores dedican menos tiempo y donde están la mayoría de los bugs.

Por qué probar a nivel de API

Podrías probarlo todo a través de las pantallas de la app. Los equipos prueban las APIs directamente por varias razones prácticas.

• Es más rápido. Una petición tarda milisegundos. Llegar al mismo estado haciendo clic en una interfaz tarda segundos, y automatizar esos clics lleva mucho más tiempo de escribir y se rompe cada vez que un botón cambia de sitio.
• La API suele existir antes. El backend y el frontend a menudo se construyen en paralelo, así que puedes empezar a probar el backend antes de que haya nada en lo que hacer clic.
• La interfaz esconde problemas. Imagina que la casilla de cantidad de una app de compras solo admite números del 1 al 10. La API que hay detrás recibe una petición normal, y cualquiera puede enviar una con una cantidad de -5. Si el servidor confía en que la app ya lo comprobó, el pedido sale con un total negativo. Eso solo lo descubres hablando con la API directamente.
• Una API suele servir a varios clientes: una web, una app de iPhone, una app de Android, una integración con un socio. Un bug en la API es un bug en todos ellos.

Las pruebas de interfaz siguen teniendo su sitio. Son la única forma de comprobar que las pantallas funcionan. Pero las reglas del sistema (quién puede ver qué, cómo es un pedido válido, qué pasa cuando se acaba el stock) viven en la API, así que es ahí donde las compruebas.