Back

Enlaces vs Formularios en Peticiones HTTP

Enlaces vs Formularios en Peticiones HTTP

Cada vez que un usuario hace clic en un enlace de navegación o envía una consulta de búsqueda, el navegador realiza una petición HTTP. Pero qué elemento HTML desencadena esa petición —y cómo— importa más de lo que la mayoría de los desarrolladores creen. Elegir entre <a> y <form> no es solo una preferencia de marcado. Es una decisión semántica que afecta el comportamiento, la seguridad y la corrección.

Puntos Clave

  • Los enlaces (<a>) son para navegación y típicamente desencadenan peticiones GET. Los formularios (<form>) son para envío de datos y soportan tanto GET como POST.
  • Usa formularios GET cuando la entrada del usuario modifica la URL (como consultas de búsqueda) y formularios POST cuando la acción cambia el estado del servidor (como la creación de cuentas).
  • method="link" es HTML inválido — los navegadores vuelven silenciosamente a GET, lo que puede llevar a comportamientos inesperados.
  • Los formularios HTML solo soportan GET y POST de forma nativa. Para PUT, PATCH o DELETE, usa JavaScript.

La Diferencia Principal: Navegación vs Envío en HTML

Los enlaces (<a>) son elementos de navegación. Le dicen al navegador: “Ve a obtener este recurso.” Hacer clic en un enlace típicamente desencadena una petición de navegación GET hacia la URL en el atributo href. Eso es todo. No se recopila entrada del usuario, no se serializan datos — solo un evento de navegación limpio.

Los formularios (<form>) son elementos de envío de datos. Recopilan entrada del usuario y la envían a un servidor. Un formulario puede usar GET o POST, dependiendo de la naturaleza de la petición.

Aquí hay una comparación rápida:

CaracterísticaEnlace <a><form>
PropósitoNavegaciónEnvío de datos
Método HTTPSolo GETGET o POST
Recopila entrada del usuarioNo
Clic derecho / abrir en nueva pestañaNo
Rastreable por SEOLimitado
Cambia estado del servidorNoSí (con POST)

GET vs POST en Formularios HTML: Cuándo Aplicar Cada Uno

Usa un enlace para navegación segura e idempotente

Si la acción no cambia nada en el servidor y el destino puede ser marcado como favorito o compartido, usa un enlace:

<a href="/articles/html-basics">Lee la guía de HTML</a>

Los enlaces son seguros, idempotentes y cacheables — exactamente lo que las peticiones GET deberían ser.

Usa un formulario GET cuando la entrada del usuario modifica la URL

Un cuadro de búsqueda es el ejemplo clásico. El usuario escribe una consulta, y el formulario la añade a la URL como una cadena de consulta:

<form method="get" action="/search">
  <input type="search" name="q" placeholder="Buscar...">
  <button type="submit">Buscar</button>
</form>

Esto produce /search?q=tu+consulta — una URL compartible y marcable como favorito. Usa formularios GET cuando la petición sigue siendo segura e idempotente, pero los parámetros de la URL dependen de la entrada del usuario.

Usa un formulario POST cuando la acción tiene efectos secundarios

Crear una cuenta, enviar un pago o publicar un comentario cambian el estado del servidor. Estos pertenecen a formularios POST:

<form method="post" action="/register">
  <input type="email" name="email">
  <input type="password" name="password">
  <button type="submit">Crear cuenta</button>
</form>

POST envía datos en el cuerpo de la petición, no en la URL — lo cual es apropiado para datos sensibles y acciones no idempotentes.

Algunos desarrolladores escriben <form method="link"> esperando crear un “botón enlace”. Esto es HTML inválido. Los navegadores ignoran el valor desconocido y vuelven al predeterminado — que es GET. El formulario aún se envía, pero lo hace de manera silenciosa e incorrecta.

Si quieres un botón que navegue a algún lugar, usa un enlace estilizado como botón — no un formulario:

<!-- ❌ Inválido -->
<form method="link" action="/about">
  <input type="submit" value="Ir a Acerca de">
</form>

<!-- ✅ Correcto -->
<a href="/about" class="btn">Ir a Acerca de</a>

Capacidades Modernas de Formularios que Vale la Pena Conocer

HTML5 añadió sobrescrituras por botón mediante los atributos formaction y formmethod, permitiendo que botones de envío individuales cambien dónde o cómo se envía un formulario:

<form method="post" action="/save">
  <button type="submit">Guardar</button>
  <button type="submit" formaction="/save-and-publish" formmethod="post">Publicar</button>
</form>

También vale la pena mencionar: requestSubmit() (a diferencia de submit()) desencadena la validación del formulario antes del envío, haciéndolo la mejor opción para el envío programático de formularios en JavaScript.

Para PUT, PATCH o DELETE, los formularios HTML no soportan estos métodos de forma nativa. Necesitarás JavaScript (fetch, XMLHttpRequest) o una convención de sobrescritura de método del lado del servidor.

Conclusión

La decisión entre enlaces y formularios es directa una vez que entiendes la semántica:

  • ¿Navegando a una página? Usa un enlace.
  • ¿Recopilando entrada del usuario para una consulta? Usa un formulario GET.
  • ¿Enviando datos que cambian el estado del servidor? Usa un formulario POST.
  • ¿Realizando PUT/PATCH/DELETE? Usa JavaScript.

Elige el elemento que coincida con la intención de la acción. El HTML semántico no es solo cuestión de corrección — es lo que hace que tu interfaz sea predecible, accesible y mantenible.

Preguntas Frecuentes

Técnicamente sí, pero usualmente es la elección semántica incorrecta. Un formulario GET está diseñado para recopilar entrada del usuario y añadirla a la URL como parámetros de consulta. Para navegación simple sin entrada del usuario, un enlace es la elección semántica correcta. Los enlaces son rastreables por motores de búsqueda, soportan menús contextuales de clic derecho, y comunican claramente la intención de navegación tanto a navegadores como a tecnologías de asistencia.

Los navegadores tratan cualquier valor de método no reconocido como inválido y vuelven silenciosamente a GET, que es el método de formulario predeterminado. Así que un formulario con method link aún se envía, pero se comporta exactamente como un formulario GET. Esto puede enmascarar errores y producir comportamientos confusos. Siempre usa get o post como valor del método de tu formulario.

El método submit() envía el formulario inmediatamente sin ejecutar la validación HTML integrada ni disparar el evento submit. El método requestSubmit() se comporta como un usuario haciendo clic en el botón de envío. Primero desencadena la validación de restricciones y dispara el evento submit, permitiendo que los escuchadores de eventos intercepten o cancelen el envío. Usa requestSubmit() cuando necesites que se ejecute la validación.

Los formularios HTML solo soportan GET y POST como valores de método. Para enviar peticiones DELETE, PUT o PATCH, necesitas JavaScript usando fetch o XMLHttpRequest. Algunos frameworks del lado del servidor también soportan un patrón de sobrescritura de método donde envías un formulario POST con un campo de entrada oculto que especifica el método HTTP deseado, que el servidor luego interpreta en consecuencia.

Gain control over your UX

See how users are using your site as if you were sitting next to them, learn and iterate faster with OpenReplay. — the open-source session replay tool for developers. Self-host it in minutes, and have complete control over your customer data. Check our GitHub repo and join the thousands of developers in our community.

OpenReplay