Si estás metiéndote en el mundo del desarrollo web, hay dos palabras que vas a ver hasta en la sopa: GET y POST. Al principio parecen chino, luego crees que las entiendes y, te lo digo por experiencia, es fácil meter la pata con ellas. Llevo más de una década en esto, y he visto a muchos programadores junior (y no tan junior) liarse con conceptos que parecen básicos pero que son el pilar de cómo funciona internet.
La verdad es que entender bien qué es una petición GET no es solo teoría barata. Es la diferencia entre construir una aplicación segura y eficiente o una chapuza que da problemas de seguridad y rendimiento. Por eso hoy voy a explicarte, sin tecnicismos absurdos y con ejemplos que sí vas a entender, qué es GET, cuándo usarlo y por qué es crucial que lo domines desde el primer día. Vamos al lío.
Lo que aprenderás en este artículo:
- Qué es una petición GET de verdad – Explicado de forma clara y con una analogía que no olvidarás para que entiendas su función principal.
- La diferencia clave entre GET y POST – Mi tabla comparativa directa al grano para que nunca más dudes cuál usar en cada situación.
- Cómo hacer tu primera petición GET con JavaScript – Te doy un trozo de código listo para copiar, pegar y entender, usando la API Fetch que se usa hoy en día.
- Los errores de novato que debes evitar – Te cuento las meteduras de pata más comunes que veo en proyectos para que no caigas en ellas.
¿Qué es exactamente una petición GET en desarrollo web?
Imagínate que internet es una biblioteca gigantesca. Tú eres el lector y el servidor web es el bibliotecario. Una petición GET es, ni más ni menos, que ir al mostrador y pedir un libro específico. Le dices al bibliotecario: «Por favor, dame el libro ‘Don Quijote de la Mancha’, de la estantería de clásicos».
En el mundo web, esto se traduce en: tu navegador (el cliente) le pide a un servidor un recurso específico. Ese «recurso» puede ser una página HTML, una imagen, un archivo CSS, o datos en formato JSON de una API. La clave aquí es que solo estás pidiendo información, no estás modificando nada en la biblioteca. No estás escribiendo en el libro, ni cambiándolo de sitio, ni quemándolo. Solo lo pides para leerlo.
Esto es lo más importante que debes entender: GET se usa para recuperar datos. Punto. Cada vez que escribes una dirección en tu navegador y le das a Enter, estás haciendo una petición GET.
La analogía que siempre uso: pedir un café
Otra forma de verlo. Entras en una cafetería:
- Petición GET: «Hola, ¿me pones un café con leche?». El camarero te lo prepara y te lo da. No has cambiado la cafetería, solo has obtenido algo que ya existía.
- Petición POST: «Hola, quiero hacerme socio de vuestro club de café y aquí tienes mi formulario de inscripción con mis datos». Aquí estás entregando información nueva para que la cafetería la guarde y modifique su estado (ahora tienen un socio más).
Sencillo, ¿verdad? Pues esta es la base de todo.
La diferencia clave: GET vs. POST (lo que el 90% no entiende bien al principio)
Aquí es donde viene el lío para muchos. «Si con ambos puedo enviar datos al servidor, ¿por qué necesito dos?». Ojo, porque la forma en que los envían y su propósito son radicalmente distintos. Para dejarlo claro de una vez por todas, te he preparado esta tabla:
| Característica | Método GET | Método POST |
|---|---|---|
| Propósito Principal | Recuperar datos de un servidor. | Enviar datos a un servidor para crear o actualizar un recurso. |
| Envío de Datos | Los datos se envían en la propia URL (ej: ?id=123&cat=libros). |
Los datos se envían en el cuerpo (body) de la petición, de forma oculta. |
| Visibilidad | Totalmente visible. Queda en el historial del navegador, logs del servidor… | Oculto. No se ve en la URL. |
| Seguridad | NUNCA usar para datos sensibles (contraseñas, emails, datos bancarios). | Mucho más seguro para enviar información sensible (aunque siempre debe ir con HTTPS). |
| Idempotencia | Sí. Hacer la misma petición 100 veces da el mismo resultado. | No. Hacer la misma petición 100 veces puede crear 100 recursos nuevos. |
| Caché | Las respuestas se pueden cachear por el navegador, lo que acelera la carga. | Las respuestas no se cachean por defecto. |
| Límite de Tamaño | Sí, limitado por la longitud máxima de la URL (unos 2048 caracteres). | No tiene un límite práctico. Puedes enviar grandes cantidades de datos. |
¿Cuándo usar GET? Las reglas de oro
La verdad es que es muy simple si sigues estas reglas:
- ✅ Para solicitar una página web, una imagen, un archivo.
- ✅ Para realizar búsquedas (lo que escribes en Google se envía por GET).
- ✅ Para obtener una lista de productos de una tienda online.
- ✅ Para pedir los datos de un usuario específico por su ID.
- ✅ En general, para cualquier operación de solo lectura.
¿Y cuándo es obligatorio usar POST?
Aquí tampoco hay duda:
- ❌ Para enviar un formulario de contacto o de inicio de sesión.
- ❌ Para crear un nuevo usuario en una base de datos.
- ❌ Para subir un archivo o una imagen.
- ❌ Para realizar una compra online.
- ❌ Cualquier operación que modifique datos en el servidor.
Cómo funciona una petición GET por dentro (sin liarte)
Cuando haces una petición GET con parámetros, estos se añaden al final de la URL en algo llamado «query string» o cadena de consulta. Es más fácil de lo que parece.
Anatomía de una URL con parámetros GET
Mira esta URL de ejemplo:
https://miapi.com/usuarios?id=42&status=activo
Vamos a desglosarla:
https://miapi.com/usuarios: Es el endpoint o la dirección del recurso que queremos consultar (la lista de usuarios).?: Este símbolo separa la URL base de los parámetros.id=42: Es el primer parámetro. Se compone de una clave (id) y un valor (42).&: Este símbolo se usa para separar múltiples parámetros.status=activo: Es el segundo parámetro, con su clave (status) y su valor (activo).
Lo que esta petición le está diciendo al servidor es: «Oye, dame los usuarios que tengan el ID 42 y cuyo estado sea activo». Fácil, ¿no?
Un ejemplo práctico con la API Fetch de JavaScript
Hoy en día, en el frontend, lo más normal es usar la API fetch que ya viene en todos los navegadores para hacer estas peticiones. Es brutalmente sencilla.
Aquí tienes un ejemplo para pedir datos a una API de prueba:
// URL de la API con los parámetros ya incluidos
const url = 'https://jsonplaceholder.typicode.com/posts?userId=1';
// Hacemos la petición GET (fetch por defecto ya es GET)
fetch(url)
.then(response => {
// Primero, comprobamos si la respuesta del servidor fue exitosa (código 200)
if (!response.ok) {
throw new Error('La respuesta de la red no fue buena');
}
// Si todo va bien, convertimos la respuesta a formato JSON
return response.json();
})
.then(data => {
// 'data' ya contiene la información que pedimos en formato de objeto JavaScript
console.log(data); // Mostramos los posts del usuario 1 en la consola
})
.catch(error => {
// Si algo falla en el proceso, lo capturamos aquí
console.error('Hubo un problema con tu petición fetch:', error);
});
Como ves, fetch por defecto hace una petición GET. No tienes que especificar el método si solo vas a pedir datos. Sencillo y directo al grano.
Errores comunes que he visto al usar GET
En mis años como consultor, he revisado mucho código. Y estos son los tres errores más típicos que te pido, por favor, que no cometas:
- Enviar contraseñas o datos sensibles por GET: Es el peor error de seguridad que puedes cometer. La URL queda registrada en todas partes. Siempre, SIEMPRE, usa POST para esto.
- Usar GET para acciones que cambian datos: He visto botones de «Eliminar usuario» que funcionan con un enlace tipo
/usuarios/eliminar?id=3. Esto es un desastre. Un buscador como Google podría rastrear ese enlace y borrarte usuarios sin querer. Las acciones de borrar, modificar o crear siempre con POST, PUT o DELETE. - No pensar en la longitud de la URL: Si necesitas enviar un formulario con muchos campos o un texto muy largo, GET no es tu amigo. La URL tiene un límite y se cortará, provocando errores.
Lo que debes recordar sobre el método GET
Si te tienes que quedar con algo de todo este artículo, que sea esto: GET es como pedir el menú en un restaurante. POST es como hacer el pedido a cocina. Con el primero, consultas información. Con el segundo, provocas un cambio.
Dominar esta diferencia no es opcional, es la base para comunicarte correctamente con cualquier servidor o API en internet. Entenderlo bien te ahorrará horas de depuración y, sobre todo, te evitará crear agujeros de seguridad garrafales. Así que la próxima vez que dudes, acuérdate del bibliotecario o del café. Verás como aciertas.
Preguntas frecuentes que me hacen sobre GET
Estas son algunas dudas que siempre surgen en mis equipos o cuando doy formación. Te las respondo directamente.
¿Puedo enviar datos en el ‘body’ de una petición GET?
Técnicamente, la especificación de HTTP no lo prohíbe, pero es una práctica terrible y no estándar. La gran mayoría de servidores y APIs ignorarán cualquier body que envíes en una petición GET. Los datos para GET van siempre en la URL. No te compliques la vida intentando reinventar la rueda.
¿Es GET más rápido que POST?
Generalmente, sí, por una razón principal: las respuestas de GET se pueden guardar en caché. Si pides la misma información varias veces, el navegador o un servidor intermedio te la puede devolver al instante sin preguntar al servidor de origen. Las peticiones POST, al modificar datos, no se cachean, por lo que siempre tienen que llegar hasta el final.
¿Qué es exactamente la «idempotencia»?
Es un palabro que simplemente significa que si haces la misma petición varias veces, el resultado en el servidor es el mismo que si la hicieras solo una vez. Pedir 10 veces los datos del usuario con ID 5 (GET) no cambia nada. En cambio, crear un usuario nuevo 10 veces (POST) resultará en 10 usuarios nuevos en tu base de datos.
¿Las peticiones GET tienen un límite de longitud?
Sí. El límite no está en el método GET en sí, sino en la longitud máxima que soportan los navegadores y servidores para una URL. No hay una cifra exacta universal, pero una buena regla es no superar los 2000 caracteres para asegurar la compatibilidad con todo. Si necesitas enviar más datos, tienes que usar POST.
