¿Cuándo se debe usar GET en lugar de POST en una aplicación web?

Question

Parece que cumplir con POST es el camino a seguir, ya que da como resultado una apariencia limpia de las URL. GET parece crear largas URL confusas. POST también es mejor en términos de seguridad. Bueno para proteger contraseñas en formularios. De hecho, he oído que muchos desarrolladores solo usan POST para formularios. También he escuchado que muchos desarrolladores nunca usan realmente GET.

Entonces, ¿por qué y en qué situación se usaría GET si POST tiene estas 2 ventajas?

¿Qué beneficio tiene GET en tener más de POST?

Answer 1

A veces desea que su aplicación web sea reconocible, ya que los usuarios pueden adivinar qué URL debe ser para una determinada operación. Proporciona una experiencia de usuario más agradable y para esto usaría GET y basaría sus URL en algún tipo de especificación RESTful como http://microformats.org/wiki/rest/urls

Answer 2

tiene la razón, sin embargo, puede ser mejor utilizar páginas de búsqueda y tal. Lugares donde DESEA que las URL sean obvias y detectables. Si nos fijamos en Google (o en cualquier página de búsqueda), pone una www.google.com/?q=my+search al final para que las personas puedan vincular directamente a la búsqueda.

Realmente usas GET mucho más de lo que crees. Simplemente devolver la página web es una solicitud GET. También hay POST, PUT, DELETE, HEAD, OPTIONS y todos estos se utilizan en las interfaces de programación RESTful.

GET frente a POST no tiene implicaciones en la seguridad, ambos son inseguros a menos que use HTTP/SSL.

Answer 3

Si por 'aplicación web' te refieres a 'sitio web', como desarrollador no tienes otra opción. No es usted, como desarrollador, quien realiza las solicitudes GET o POST, es su usuario. Ellos hacen las solicitudes a través de su navegador web.

Cuando solicita una página web escribiendo su URL en la barra de direcciones del navegador (o haciendo clic en un enlace, etc.), el navegador emite una solicitud GET.

Cuando envía una página web con un botón, realiza una solicitud POST.

En una solicitud GET, se envían datos adicionales en la cadena de consulta. Por ejemplo, la URL www.misitio.com?user=david & password = fish envía los dos bits de datos 'usuario' y 'contraseña'.

En una solicitud POST, se envían los valores en los controles del formulario (por ejemplo, cuadros de texto, etc.). Esto no es visible en la barra de direcciones, pero es completamente visible para cualquiera que vea su tráfico web.

Tanto GET como POST son completamente inseguros a menos que se use SSL (por ejemplo, direcciones web que comiencen por https).

Answer 4

Check the manual, me sorprende que nadie haya señalado que GET y POST sean semánticamente diferentes y destinados a fines muy diferentes.

Si bien puede parecer que en muchos casos no existe una diferencia funcional entre los 2 enfoques, hasta que haya probado todas las combinaciones de navegador, proxy y servidor no podrá confiar en que sea consistente en todos los casos. p.ej.los dispositivos móviles/proxies a menudo almacenan en caché agresivamente, incluso cuando se les solicita que no lo hagan (pero nunca he encontrado uno que guarde incorrectamente una respuesta POST).

El protocolo no admite más que tipos de datos escalares simples como parámetros en un OBTENCIÓN - p. Ej. solo puede enviar un archivo usando POST o PUT.

También hay limitaciones de implementación: la última vez que revisé, el tamaño de una URL se limitó a alrededor de 2k en MSIE.

Finalmente, como ha notado, está la cuestión de la visibilidad de los datos: es posible que no desee permitir que los usuarios marquen como favorito una URL que contenga su número de tarjeta de crédito/contraseña.

POST es el camino a seguir, ya que da lugar a un aspecto limpio URL

que en lugar contra del propósito de lo que una URL se trata. Lea RFC 1630 - La necesidad de una sintaxis universal.