GET

Uso

Una solicitud GET recupera datos sin modificar el estado del servidor. Cualquier contenido del cuerpo de la solicitud carece de semántica definida con carácter general, y toda la consulta se expresa mediante el URI de destino y las cabeceras. Las respuestas son almacenables en caché de forma predeterminada, lo que convierte a GET en la base del almacenamiento en caché de la Web.

GET es el método predeterminado del navegador para la navegación, los clics en enlaces y los envíos de formularios sin atributo method.

La especificación HTTP no prohíbe un cuerpo en las solicitudes GET, pero la semántica de ese cuerpo no está definida. Los navegadores y la Fetch API eliminan los cuerpos de las solicitudes GET. Muchos servidores y proxies los ignoran o los rechazan. Depender de un cuerpo en una solicitud GET no es seguro para la interoperabilidad.

Propiedades

Como GET es seguro e idempotente, enviar la misma solicitud varias veces produce el mismo resultado y no altera el recurso. Los navegadores, los rastreadores y los proxies dependen de esta garantía.

GET condicional

Una solicitud GET pasa a ser condicional cuando incluye una o varias cabeceras de validación: If-Match, If-None-Match, If-Modified-Since, If-Unmodified-Since o If-Range. El servidor evalúa la condición y devuelve la representación completa solo cuando se cumple.

GET parcial

Incluir una cabecera Range convierte un GET en una solicitud parcial. El servidor devuelve únicamente el rango de bytes solicitado con un estado 206. Un estado 416 indica que el rango no se puede satisfacer. Los servidores que no admiten solicitudes de rango devuelven 200 con el cuerpo completo.

El GET parcial resulta útil para reanudar descargas interrumpidas y para transmitir archivos grandes por segmentos.

GET básico

Una solicitud GET mínima recupera el recurso raíz. El servidor devuelve 200 con la representación completa.

Solicitud

GET / HTTP/1.1
Host: example.com

Respuesta

HTTP/1.1 200 OK
Content-Type: text/html
Content-Length: 1256

<!doctype html>
<html>...

GET condicional

Esta solicitud incluye If-Modified-Since, de modo que el servidor devuelve el cuerpo solo cuando el recurso ha cambiado desde la fecha indicada. Un recurso sin cambios produce un 304 sin cuerpo.

Solicitud

GET / HTTP/1.1
Host: example.com
If-Modified-Since: Sat, 01 Jan 2022 12:00:00 GMT

Respuesta (no modificada)

HTTP/1.1 304 Not Modified
ETag: "abc123"

GET parcial

La cabecera Range solicita únicamente los primeros 512 bytes. El servidor responde con 206 y una cabecera Content-Range que indica el segmento devuelto.

Solicitud

GET /file.bin HTTP/1.1
Host: example.com
Range: bytes=0-511

Respuesta

HTTP/1.1 206 Partial Content
Content-Range: bytes 0-511/8192
Content-Length: 512

CORS

GET es un método incluido en la lista segura de CORS. Las solicitudes GET de origen cruzado no desencadenan una solicitud de verificación previa, lo que convierte a GET en el método predeterminado para obtener recursos de origen cruzado en los navegadores.

GET frente a POST

GET recupera datos. POST envía datos para su procesamiento. Los parámetros de GET viajan en la cadena de consulta de la URL, mientras que los de POST van en el cuerpo de la solicitud.

Las respuestas GET son almacenables en caché y se pueden guardar como marcador. Las respuestas POST solo son almacenables en caché con información de frescura explícita. Las URL tienen límites prácticos de longitud, lo que restringe la cantidad de datos que puede llevar un GET. POST no tiene un límite práctico de tamaño de cuerpo.

GET es a la vez seguro e idempotente. POST no es ninguna de las dos cosas. Un GET repetido devuelve el mismo resultado. Un POST repetido crea recursos duplicados o desencadena el procesamiento dos veces.

La diferencia de rendimiento entre GET y POST es insignificante. La elección depende de la operación: para recuperar se usa GET, para enviar se usa POST.

Seguridad

Los parámetros de GET son visibles en la URL, el historial del navegador, los registros del servidor y las cabeceras Referer. Los datos sensibles, como contraseñas, tokens e información de identificación personal, nunca deben aparecer en las cadenas de consulta.

Las solicitudes GET están más expuestas a los ataques CSRF a través de etiquetas y que desencadenan solicitudes GET automáticamente. POST también es vulnerable a CSRF si no se usan tokens adecuados.

Ni GET ni POST proporcionan cifrado por sí mismos. Es necesario HTTPS para proteger los datos en tránsito.

Impacto en SEO

Los motores de búsqueda rastrean con GET. Googlebot y otros rastreadores obtienen e indexan las páginas mediante GET, por lo que un recurso solo es detectable cuando responde a un GET simple. Las respuestas GET almacenables en caché e idempotentes se rastrean con la máxima eficiencia, ya que los rastreadores reutilizan validadores como ETag y Last-Modified para evitar volver a descargar páginas sin cambios.