Método GET

Definición

GET es el método HTTP más común - recupera datos de un servidor. Cuando escribes una URL en tu navegador, visitas una página web, o cargas una imagen, tu navegador envía peticiones GET. GET significa “dame este recurso” sin cambiar nada en el servidor.

GET es tanto safe (sin efectos secundarios - leer no modifica datos) como idempotente (llamarlo múltiples veces tiene el mismo efecto que llamarlo una vez). Esto hace que las peticiones GET sean perfectas para caché, marcadores y refrescos.

Las peticiones GET nunca deberían modificar el estado del servidor. Los parámetros van en la query string de la URL (/users?role=admin), no en un cuerpo de petición. La respuesta puede ser cacheada por navegadores e intermediarios, haciendo de GET el método HTTP más eficiente.

Ejemplo

Navegación Web: Cuando visitas https://example.com, tu navegador envía GET / [HTTP/1.1](https://reference.apios.info/es/terms/http-1-1/). El servidor retorna el HTML de la página de inicio.

Obtención de Datos de API: Una app de clima envía GET /api/weather?city=NYC para obtener el clima actual. El parámetro de ciudad va en la URL.

Carga de Imágenes: Cada imagen en una página web requiere una petición GET. <img src="/logo.png"> dispara GET /logo.png.

Resultados de Búsqueda: Google usa GET para búsquedas: GET /search?q=http+methods. La consulta va en la URL, por lo que puedes marcar o compartir el enlace.

Paginación: Listar posts de blog con GET /posts?page=2&limit=10 recupera la segunda página de resultados.

Analogía

Catálogo de Biblioteca: Usar GET es como buscar libros en el catálogo de una biblioteca - solo estás leyendo información, no sacando libros ni cambiando el inventario de la biblioteca. Puedes mirar la misma entrada cien veces sin afectar nada.

Menú de Restaurante: Leer un menú es una petición GET - estás recopilando información sin hacer un pedido. El menú no cambia porque lo hayas mirado.

Consulta de Saldo en Cajero: Consultar tu saldo es GET - estás viendo información sin retirar dinero. Puedes consultar tu saldo repetidamente sin afectar el saldo.

Ejemplo de Código

// Petición GET simple
GET /api/users/123 HTTP/1.1
Host: api.example.com
Accept: application/json

// GET con parámetros de consulta
GET /api/users?role=admin&status=active HTTP/1.1
Host: api.example.com
Accept: application/json

// Respuesta
HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: max-age=300
ETag: "33a64df551425fcc55e4d42a148795d9"

{
  "id": 123,
  "name": "Alice",
  "email": "[email protected]",
  "role": "admin"
}

Diagrama

sequenceDiagram
participant Client
participant Cache
participant Server
Client->>Cache: GET /api/users/123
Cache-->>Client: Cache miss
Client->>Server: GET /api/users/123
Server->>Server: Leer datos (sin modificación)
Server->>Client: 200 OK + Datos
Client->>Cache: Guardar en caché
Note over Client,Server: Safe & Idempotente: sin efectos secundarios

Notas de Seguridad

Mejores Prácticas

1. Usa GET solo para obtener datos, nunca para modificaciones
2. Mantén las peticiones GET safe (sin efectos secundarios) e idempotentes
3. Pon parámetros en query string, no en body (algunos clientes ignoran el body)
4. Usa códigos de estado apropiados (200 OK, 404 Not Found, 304 Not Modified)
5. Soporta caché con headers Cache-Control, ETag, Last-Modified
6. Implementa paginación para colecciones grandes
7. Soporta filtrado y ordenamiento vía parámetros de consulta
8. Nunca incluyas datos sensibles en URLs
9. Valida y sanitiza todos los parámetros de consulta
10. Retorna formato de respuesta consistente (JSON, XML, etc.)

Errores Comunes

Usar GET para modificar datos (rompe semántica safe), poner datos sensibles en URLs, ignorar headers de caché, retornar 200 para no encontrado (usa 404), no soportar peticiones condicionales (If-None-Match, If-Modified-Since), aceptar request body en GET (muchos clientes no lo envían), no validar parámetros de consulta, falta de paginación para resultados grandes, manejo pobre de errores.

Estándares y RFCs

Términos Relacionados