≡En resumen
- GET pide al servidor una representación de un recurso; no debe usarse para crear, modificar ni borrar datos.
- Los parámetros viajan en la URL, así que quedan en el historial, en los logs del servidor y pueden filtrarse: nunca envíes contraseñas ni datos personales por GET.
- Al ser seguro e idempotente, un GET se puede repetir, cachear, guardar en marcadores y compartir sin efectos secundarios.
- Usa GET para leer y POST (o PUT, PATCH, DELETE) para cambiar el estado del servidor.
- Desde 2026 existe QUERY, un método seguro e idempotente que admite cuerpo para consultas demasiado grandes para la URL.
01 ¿Qué es el método HTTP GET?
Cada vez que abres una página web, tu navegador envía al servidor una petición HTTP. Esa petición empieza siempre con un método (también llamado verbo) que indica qué quieres hacer con el recurso. GET (en inglés, «obtener») es el más usado de todos: significa «dame este recurso».
Con un GET pides una página HTML, una hoja de estilos, una imagen, un vídeo o la respuesta en JSON de una API. El servidor responde con un código de estado, unas cabeceras y, normalmente, el contenido solicitado en el cuerpo de la respuesta.
| Propiedad | ¿GET la cumple? | Qué significa en la práctica |
|---|---|---|
| Seguro (safe) | Sí | No debe provocar cambios en el servidor: solo lectura. |
| Idempotente | Sí | Repetir la misma petición produce el mismo efecto que hacerla una vez. |
| Cacheable | Sí | El navegador, un proxy o una CDN pueden guardar la respuesta y reutilizarla. |
| Cuerpo en la petición | No recomendado | Un cuerpo en un GET no tiene significado definido y algunos servidores lo rechazan. |
| Cuerpo en la respuesta | Sí | La respuesta correcta incluye el recurso pedido. |
| Permitido en formularios HTML | Sí | Es el método por defecto de un formulario si no indicas otro. |
02 Cómo funciona una petición GET paso a paso
Aunque para ti solo es escribir una dirección y pulsar Intro, detrás hay un intercambio muy concreto entre cliente y servidor. Este es el recorrido de un GET típico cuando visitas una URL:
-
1
El cliente prepara la petición
El navegador (o una app, o un script) toma la URL, separa el dominio, la ruta y los parámetros, y construye la línea de petición: GET /ruta?parametros HTTP/1.1.
-
2
Añade las cabeceras
Incluye cabeceras como Host (el dominio), Accept (qué formatos acepta), Accept-Language, User-Agent o las cookies de sesión.
-
3
Se envía al servidor
Tras resolver el DNS y abrir la conexión (cifrada con TLS si es HTTPS), la petición viaja al servidor web.
-
4
El servidor procesa y responde
Localiza el recurso y devuelve un código de estado (200, 304, 404…), cabeceras como Content-Type o Cache-Control y el cuerpo con el contenido.
-
5
El navegador pinta y pide más
Al leer el HTML descubre imágenes, CSS y JavaScript, y lanza un nuevo GET por cada recurso que necesita.
Petición:GET /diccionario/?q=api HTTP/1.1Host: www.ejemplo.comAccept: text/htmlUser-Agent: Mozilla/5.0
Respuesta:HTTP/1.1 200 OKContent-Type: text/html; charset=UTF-8Cache-Control: max-age=3600<!doctype html> …
La primera línea de la respuesta es el código de respuesta 200 OK: todo ha ido bien y el cuerpo trae la página.
03 Parámetros GET: cómo se envían datos en la URL
GET no lleva cuerpo, así que los datos que quieras enviar van en la propia URL, detrás de un signo de interrogación. Esa parte se llama query string y se compone de pares clave=valor separados por &. Por ejemplo: /tienda?categoria=zapatillas&talla=42&pagina=2.
Los caracteres especiales (espacios, tildes, &, =…) deben codificarse: un espacio se convierte en %20 o + y la «ñ» en %C3%B1. Los navegadores y las librerías HTTP lo hacen por ti.
Búsquedas
El término que escribes en un buscador interno suele viajar como ?q=palabra, de modo que puedes compartir el enlace con los resultados.
Filtros y orden
Precio, talla, color u orden de un listado: cada filtro es un parámetro GET y cada combinación genera una URL distinta.
Paginación
Parámetros como ?page=3 indican qué página de resultados quieres ver.
Seguimiento de campañas
Los parámetros UTM (utm_source, utm_medium…) identifican de dónde viene una visita en analítica.
04 Diferencias entre GET y POST
Es la duda más habitual. Un error frecuente (y que todavía aparece en muchos tutoriales) es decir que GET es «más seguro» que POST. No es así: GET es seguro en el sentido técnico de que no modifica datos, pero expone los parámetros en la URL. La elección depende de lo que haga la petición, no de la comodidad.
| Aspecto | GET | POST |
|---|---|---|
| Para qué sirve | Leer u obtener un recurso | Enviar datos para que el servidor los procese (crear, registrar, pagar…) |
| Dónde van los datos | En la URL (query string) | En el cuerpo de la petición |
| Seguro / idempotente | Sí / Sí | No / No |
| Cacheable | Sí, por defecto si las cabeceras lo permiten | Solo con indicaciones explícitas; en la práctica casi nunca |
| Marcadores e historial | Se puede guardar y compartir | No se puede guardar como enlace |
| Al recargar la página | Se repite sin avisos | El navegador pide confirmación para reenviar |
| Datos sensibles | Nunca | Sí, siempre sobre HTTPS |
| Ejemplos | Ver un producto, buscar, filtrar, paginar | Login, formulario de contacto, alta de pedido, subida de archivos |
05 GET y el resto de métodos de petición HTTP
GET forma parte de una familia de métodos. La RFC 9110 define ocho (GET, HEAD, POST, PUT, DELETE, CONNECT, OPTIONS y TRACE); PATCH llegó en la RFC 5789 y, en junio de 2026, la RFC 10008 añadió QUERY, el primer método estándar nuevo en muchos años. Así se comparan:
| Método | Uso principal | Seguro | Idempotente |
|---|---|---|---|
| GET | Obtener un recurso | Sí | Sí |
| HEAD | Igual que GET pero sin cuerpo: solo cabeceras | Sí | Sí |
| QUERY | Consulta segura con los criterios en el cuerpo | Sí | Sí |
| OPTIONS | Consultar qué métodos admite un recurso (por ejemplo, en CORS) | Sí | Sí |
| TRACE | Prueba de bucle de la petición (diagnóstico) | Sí | Sí |
| POST | Enviar datos para procesar o crear | No | No |
| PUT | Crear o reemplazar un recurso completo | No | Sí |
| PATCH | Modificar parcialmente un recurso | No | No (salvo que se diseñe así) |
| DELETE | Eliminar un recurso | No | Sí |
| CONNECT | Abrir un túnel, normalmente a través de un proxy | No | No |
06 Cómo hacer una petición GET: ejemplos en HTML, JavaScript y cURL
En el día a día harás peticiones GET desde formularios, desde el frontend y desde la terminal para probar una API REST. Estos son los casos más comunes, listos para copiar:
<form action="/buscar" method="get"><input name="q" type="search"><button>Buscar</button></form>
Al enviarlo, el navegador va a /buscar?q=lo+que+escribas. Si omites method, el formulario usa GET por defecto.
const url = new URL('https://api.ejemplo.com/productos');url.searchParams.set('categoria', 'zapatillas');const res = await fetch(url); // GET es el método por defectoconst datos = await res.json();
URLSearchParams se encarga de codificar los valores correctamente.
curl -i "https://api.ejemplo.com/productos?categoria=zapatillas"
La opción -i muestra también las cabeceras de la respuesta. En el servidor, PHP expone los parámetros en $_GET['categoria'], Laravel con $request->query('categoria') y Express (Node.js) con req.query.categoria.
Si estás construyendo una plataforma con muchas integraciones, diseñar bien qué endpoints son GET y cuáles no es parte del trabajo de arquitectura. Es algo que cuidamos desde el primer sprint en el desarrollo de aplicaciones web a medida.
07 Respuestas a un GET: códigos de estado y caché
Como GET es cacheable, bien configurado ahorra peticiones y acelera la carga. El servidor indica cuánto tiempo puede reutilizarse una respuesta con Cache-Control y la identifica con ETag o Last-Modified. En la siguiente visita, el navegador lanza un GET condicional (If-None-Match, If-Modified-Since) y, si nada ha cambiado, recibe un 304 sin cuerpo. Es una de las bases de la caché web y de cualquier trabajo serio sobre la velocidad de carga web.
| Código | Significado | Cuándo aparece |
|---|---|---|
| 200 OK | Petición correcta | El recurso existe y va en el cuerpo. |
| 206 Partial Content | Contenido parcial | Se pidió un rango (cabecera Range), típico en vídeo y descargas. |
| 301 / 308 | Redirección permanente | El recurso cambió de URL para siempre. |
| 302 / 307 | Redirección temporal | El recurso está provisionalmente en otra URL. |
| 304 Not Modified | Sin cambios | Respuesta a un GET condicional: usa tu copia en caché. |
| 404 Not Found | No encontrado | La URL no corresponde a ningún recurso. |
| 405 Method Not Allowed | Método no permitido | El recurso no admite GET (por ejemplo, un endpoint solo POST). |
| 414 URI Too Long | URL demasiado larga | La query string supera lo que acepta el servidor. |
08 HTTP GET, SEO y buenas prácticas de desarrollo
Los rastreadores de los buscadores recorren la web sobre todo con peticiones GET, así que lo que devuelvas a un GET es lo que Google puede ver e indexar. Esto tiene dos consecuencias directas: cada combinación de parámetros es una URL distinta (filtros, orden, UTM) y un enlace que ejecuta acciones por GET puede ser «pulsado» por un bot.
Por eso en una auditoría SEO técnica se revisan las URLs con parámetros, las etiquetas canonical y qué facetas deben o no rastrearse.
- ✓Usa GET solo para leer: nunca borres, compres ni des de baja nada con un enlace GET.
- ✓No pongas contraseñas, tokens ni datos personales en la query string.
- ✓Declara una URL canónica cuando varios parámetros muestran el mismo contenido.
- ✓Mantén un orden estable de parámetros y evita duplicados como ?a=1&b=2 y ?b=2&a=1.
- ✓Configura Cache-Control y ETag en las respuestas GET que se puedan reutilizar.
- ✓Devuelve el código correcto: 404 si no existe, 405 si el método no está permitido, 301 si ha cambiado de URL.
- ✓Si la consulta no cabe en la URL, valora QUERY o un POST de búsqueda bien documentado.
Preguntas frecuentes sobre HTTP GET
Es el método de petición que se usa para obtener un recurso de un servidor, como una página, una imagen o datos de una API. Es seguro, idempotente y cacheable, y sus parámetros viajan en la URL.
Técnicamente se puede enviar, pero la RFC 9110 establece que un cuerpo en un GET no tiene semántica definida y algunos servidores lo rechazan. Si necesitas enviar criterios en el cuerpo, usa QUERY o POST.
Para datos sensibles, POST, porque los datos van en el cuerpo y no quedan en la URL, el historial ni los logs. Ninguno de los dos cifra nada: el cifrado lo aporta HTTPS.
No hay un máximo oficial. La RFC 9110 recomienda soportar al menos 8.000 octetos; por encima, el servidor puede responder 414 URI Too Long.
Que repetir la misma petición una o muchas veces tiene el mismo efecto en el servidor. Por eso el navegador puede recargar o reintentar un GET sin pedirte confirmación.
HEAD funciona igual que GET pero el servidor devuelve solo las cabeceras, sin cuerpo. Sirve para comprobar si un recurso existe, su tamaño o si ha cambiado sin descargarlo.
Es un método HTTP estandarizado en la RFC 10008 (junio de 2026) que permite enviar una consulta en el cuerpo de la petición manteniendo las garantías de GET: es seguro e idempotente.
Fuentes consultadas
Sobre el autor
Germán Gutiérrez
Development Manager en appyweb
Dirige el equipo de desarrollo de appyweb: aplicaciones web y móviles, SaaS, integraciones y arquitectura de software.
Ver perfil en LinkedIn ↗