Probador de API REST
Herramienta para probar APIs REST.
Solicitud
Respuesta
| Estado | {{ status }} |
|---|---|
| Cabeceras | {{ hkey }}: {{ hval }} |
* No se pueden obtener datos a menos que la API incluya el encabezado 'Access-Control-Allow-Origin': *. Considera usar la extensión correspondiente si usas Google Chrome.
https://chromewebstore.google.com/detail/cors-unblock/lfhmikememgdcahcdlaciloancbhjino
¿Qué es un probador de API REST?
Un probador de API REST le permite elegir un método HTTP (GET, POST, PUT, DELETE, etc.), enviar una petición a un extremo desde el navegador y examinar en el acto el código de estado, las cabeceras y el cuerpo de la respuesta. Así comprueba el comportamiento de una API sin instalar una aplicación de escritorio como Postman ni recurrir a cURL en la línea de comandos.
Resulta adecuado para verificar el comportamiento mientras desarrolla una API, o para tantear una API pública y conocer la forma de sus respuestas antes incluso de leer la documentación. Tenga en cuenta, eso sí, que como las peticiones salen directamente del navegador, no recibirá respuesta si la API de destino no permite CORS (la cabecera Access-Control-Allow-Origin).
Cómo usar el probador de API REST
- Seleccione el método HTTP Elija el método correspondiente a la operación que desea: GET, POST, PUT, PATCH, DELETE, etc.
- Introduzca la URL del extremo Indique la URL de la API a la que consulta. Facilite una URL completa que empiece por https.
- Defina cabeceras y cuerpo si es necesario Introduzca cabeceras como un token de autenticación o Content-Type, y el cuerpo JSON que envía con POST o PUT.
- Envíe y examine la respuesta El código de estado, las cabeceras y el cuerpo de la respuesta se muestran allí mismo.
Consejos para aprovecharla mejor
- Las restricciones CORS impiden hacer peticiones directas a APIs sin la cabecera
Access-Control-Allow-Origin. Usa APIs públicas o APIs con CORS habilitado. - Añade
Content-Type: application/jsona las cabeceras de la solicitud para enviar un cuerpo JSON. - Códigos de estado HTTP: 2xx=éxito, 4xx=error del cliente (401=no autorizado, 404=no encontrado), 5xx=error del servidor.
- Para APIs que requieren autenticación Bearer Token, añade
Authorization: Bearer {token}a las cabeceras.
Cuándo resulta útil un probador de API REST
Comprobar una API en desarrollo
Vea al instante si la API de servidor que está construyendo devuelve la respuesta prevista, mientras aún la está escribiendo.
Investigar la forma de las respuestas de una API pública
Antes de leer la documentación de un servicio externo, envíe una petición real y observe la estructura JSON que llega.
Verificar las cabeceras de autenticación
Pruebe si una petición que lleva un token Bearer o una clave de API se autentica correctamente.
Ver qué contiene una respuesta de error
Envíe a propósito un parámetro no válido y compruebe qué mensaje de error y qué código de estado devuelve la API.
Glosario
- REST
- Siglas de Representational State Transfer. Un estilo de diseño de API web en el que los recursos se manipulan mediante métodos HTTP y URL.
- CORS
- Siglas de Cross-Origin Resource Sharing. El mecanismo con el que los navegadores restringen las peticiones a otro origen (dominio): mientras el servidor de la API no devuelva la cabecera que lo permite, la respuesta no puede leerse.
- Extremo (endpoint)
- La URL en la que una API acepta peticiones. Por ejemplo «/api/users», que señala el recurso sobre el que se opera.
- Método HTTP
- El identificador que indica el tipo de petición. Entre ellos están GET (obtener), POST (crear), PUT (actualizar) y DELETE (eliminar).
- Token Bearer
- Un formato de token muy usado para la autenticación de API. Se añade a la cabecera de la petición con la forma «Authorization: Bearer {token}».
Preguntas frecuentes
Access-Control-Allow-Origin, el navegador la bloqueará. Usa una API pública o con CORS habilitado, o instala una extensión como CORS Unblock.Content-Type: application/json a las cabeceras de la solicitud e introduce una cadena JSON válida en el campo del cuerpo antes de enviar.Authorization: Bearer {your_token} a las cabeceras de la solicitud, reemplazando {your_token} con el valor real de tu token.
A propósito — El nacimiento de REST: cómo la tesis doctoral de Roy Fielding cambió el desarrollo web
REST fue propuesto en el año 2000 por Roy Fielding en su tesis doctoral "Architectural Styles and the Design of Network-based Software Architectures". Fielding fue uno de los principales coautores de la especificación HTTP/1.1, y el concepto REST nació mientras organizaba los principios de diseño detrás de HTTP.
Twitter migró de SOAP a REST API alrededor de 2010 y la abrió a los desarrolladores, lo que disparó su adopción masiva. Hoy en día, servicios como Stripe, GitHub, Slack y OpenAI (ChatGPT) ofrecen REST APIs, formando lo que se conoce como la "economía de APIs".
El diseño de REST incluye originalmente la restricción "Hypermedia as the Engine of Application State (HATEOAS)", pero muy pocos servicios la implementan estrictamente. El debate sobre "si algo es verdaderamente RESTful" resurge periódicamente en la comunidad de desarrollo web y la definición sigue siendo objeto de controversia.