GET vs. POST ¿realmente importa?

Question

Ok, sé la diferencia de propósito. GET es para obtener algunos datos. Haz una solicitud y recupera datos. POST se debe usar para operaciones CRUD distintas a las de lectura, creo. Pero a fin de cuentas, ¿realmente le importa al servidor si recibe un GET vs. POST al final?

Answer 1

Dado que usted es el que escribe el software del servidor (presumiblemente), entonces le importa si le dice que se preocupe. Si maneja los datos POST y GET de forma idéntica, entonces no, no es así.

Sin embargo, el navegador definitivamente se preocupa. Al actualizar o al hacer clic de nuevo en una página que recibió como respuesta a un mensaje POST aparece el pequeño mensaje "¿Está seguro de que desea enviar datos otra vez?", Por ejemplo.

Answer 2

¿El usuario debería poder marcar la página resultante? Otra cosa en la que pensar es que algunos navegadores/servidores limitan incorrectamente la longitud del URI de OBTENCIÓN.

Editar: nota de restricción de longitud de carga corregida - gracias ars!

Answer 3

No, no deben excepto para @ jbruce2112 responder y cargar archivos requieren POST.

Answer 4

GET tiene limitaciones en el lado del navegador. Por ejemplo, some browsers limitan la longitud de las solicitudes GET.

Answer 5

Creo que una respuesta más adecuada, es que puedes hacer las mismas cosas con ambos. No es tanto una cuestión de preferencia, sin embargo, sino una cuestión de uso correcto. Yo recomendaría que use sus GET y POST como estaban destinados a para ser utilizados.

Answer 6

Lo hace si un motor de búsqueda está rastreando la página, ya que estarán realizando solicitudes GET pero no POST. Digamos que tiene un enlace en su página:

http://www.example.com/items.aspx?id=5&mode=delete 

sin algún tipo de comprobación de autorización realizada antes de la eliminación, es posible que el robot de Google podría come in and delete items de su página.

Answer 7

Depende del software en el extremo del servidor. Algunas bibliotecas, como CGI.pm en perl, manejan ambas de forma predeterminada. Pero hay situaciones en las que más o menos tiene que usar POST en lugar de GET, al menos para enviar datos al servidor. Grandes cantidades de datos (donde la URL GET correspondiente sería demasiado larga), datos binarios (para evitar muchos problemas de codificación/descodificación), archivos multiparte, encabezados no analizados (para actualizaciones continuas, estilo pre-AJAX ...) y similares .

Answer 8

El servidor técnicamente no podría importarle de una forma u otra sobre qué tipo de solicitud recibe. Ejecutará ciegamente cualquier solicitud que cruce el cable.

Cual es el problema. Si tiene una acción que destruye o modifica los datos en una acción GET, Google destruirá su sitio mientras rastrea a través de la indexación.

Answer 9

Por lo general, al servidor no le importa. Pero es principalmente para seguir buenas prácticas, como mencionaste. El lado del cliente también importa: como se mencionó, no se puede marcar una página POST'd por lo general, y algunos navegadores tienen límites en la longitud de la URL para consultas GET realmente largas.

Answer 10

Si utiliza una solicitud GET para alterar el estado del servidor, corre el riesgo de que sucedan cosas malas si un webcrawler atraviesa su sitio.Cuando los wikis se hicieron populares por primera vez, se borraron historias de horror de sitios completos porque la función "eliminar página" se implementó como una solicitud GET, con resultados desastrosos cuando el robot de Google llamó ...

Answer 11

Dado que GET está diseñado para especificando el recurso que desea obtener, dependiendo del software exacto en el lado del servidor, el servidor web (o el equilibrador de carga) puede tener un límite de tamaño en las solicitudes GET para evitar ataques de denegación de servicio ...

Answer 12

" Use GET si: la interacción es más como una pregunta (es decir, es una operación segura, como una consulta, operación de lectura o búsqueda) ".

"Use POST si: la interacción es más parecida a un pedido, o la interacción cambia el estado del recurso de una manera que el usuario perciba (por ejemplo, una suscripción a un servicio) o el usuario debe rendir cuentas para los resultados de la interacción ".

source

Answer 13

De acuerdo con el RFC HTTP GET no deberían tener ningún efecto secundario, mientras que el poste puede tener efectos secundarios.

El ejemplo más básico de esto es que GET no es apropiado para nada como una transacción de compra o publicar un artículo en un blog, mientras que POST es apropiado para acciones que tienen consecuencias.

Mediante el RFC, puede mantener a un usuario responsable de las acciones realizadas por POST (como una compra), pero no para las acciones GET. 'Bots siempre usan GET por este motivo.

Desde el RFC 2616, 9.1.1:

9.1.1 Métodos seguros

Los ejecutores deben ser conscientes de que el software representa al usuario en
sus interacciones a través de Internet, y hay que tener cuidado para permitir que el usuario tenga conocimiento de cualquier acción que pueda tomar que pueda tener un
u importancia nexpected para ellos mismos u otros.

En particular, la Convención ha ha establecido que el GET y
métodos cabeza no debe tener la importancia de tomar una acción
aparte de la recuperación. Estos métodos deben considerarse "seguros". Este permite a los agentes de usuario para representar otros métodos, tales como POST, PUT y DELETE, de una manera especial, para que el usuario se hace consciente del hecho de que una acción posiblemente peligroso está siendo solicitada.

Naturalmente, no es posible garantizar que el servidor no
generar efectos secundarios como resultado de realizar una solicitud GET; de hecho, algunos recursos dinámicos consideran que es una característica . La importante distinción aquí es que el usuario no solicitó los efectos secundarios, por lo tanto, no se hace responsable de ellos.

Answer 14

GET tiene restricciones de límite de datos basados ​​en el navegador envía:

La especificación de longitud de URL no dicta una longitud máxima URL mínimo o, pero su aplicación varía según el navegador. En Windows: Opera admite ~ 4050 caracteres, IE 4.0+ admite exactamente 2083 caracteres, Netscape 3 -> 4.78 admite hasta 8192 caracteres antes de causar errores al apagar, y Netscape 6 admite ~ 2000 antes de causar errores en la puesta en marcha

Answer 15

Tenga en cuenta que los navegadores pueden almacenar en caché las solicitudes GET, pero generalmente no almacenarán en caché las solicitudes POST.

Answer 16

Según las especificaciones HTTP, GET es seguro e idempotente y POST no lo es. Lo que esto significa es que una solicitud GET se puede repetir varias veces sin causar efectos secundarios.

Incluso si a su servidor no le importa (y esto es poco probable), puede haber agentes intermedios entre su cliente y el servidor, todos los cuales tienen esta expectativa. Por ejemplo, proxies para almacenar datos en caché en su ISP u otros proveedores para un mejor rendimiento. La misma expectativa es cierta para los aceleradores, por ejemplo, un complemento de captación previa para su navegador.

Por lo tanto, una solicitud GET se puede almacenar en caché (en función de ciertos parámetros), y si falla, se puede repetir automáticamente sin ningún tipo de efectos nocivos. Entonces, realmente su servidor debe esforzarse por cumplir este contrato.

Por otro lado, POST no es seguro, no es idempotente y cada agente sabe que no debe almacenar en caché los resultados de una solicitud POST, o reintenta una solicitud POST automáticamente. Entonces, por ejemplo, una transacción de tarjeta de crédito nunca sería una solicitud GET (no desea que las cuentas se debiten varias veces debido a errores de red, etc.).

Esa es una versión muy básica de esto. Para obtener más información, puede considerar el libro "RESTful Web Services" de Ruby and Richardson (O'Reilly press).

Para una toma rápida sobre el tema de descanso, considere este mensaje:

http://www.25hoursaday.com/weblog/2008/08/17/ExplainingRESTToDamienKatz.aspx

Lo curioso es que la mayoría de la gente debate los méritos de PUT v POST. El problema GET v POST está, y siempre ha estado, muy bien resuelto. Ignora bajo tu propio riesgo.

Answer 17

Tenga en cuenta algunas diferencias de seguridad sutiles. Ver mi pregunta

GET versus POST in terms of security?

Esencialmente lo importante es recordar que reciba le entrar en el historial del navegador y se transmitirá a través de apoderados en texto plano, por lo que no desea ninguna información sensible , como una contraseña en un GET.

Obviamente tal vez, pero vale la pena mencionarlo.

Answer 18

Sí, importa. GET y POST son bastante diferentes, realmente.

Tiene razón en que normalmente, GET es para "obtener" datos del servidor y mostrar una página, mientras que POST es para "publicar" datos de nuevo en el servidor. Internamente, sus scripts obtienen los mismos datos, ya sea GET o POST, por lo que no, al servidor realmente no le importa.

La principal diferencia es que los parámetros GET se especifican en las URL, mientras que POST no. Esta es la razón por la que POST se utiliza para los formularios de inicio de sesión y de inicio de sesión; no desea que su contraseña ingrese en una URL. Del mismo modo, si está viendo diferentes páginas o muestra una vista específica de algunos datos, normalmente quiere una URL única.

Answer 19

Técnicamente, no. Todo GET hace es publicar las cosas en la primera línea de la solicitud HTTP, y POST publica cosas en el cuerpo.

Sin embargo, cómo la "infraestructura web" trata las diferencias hace una gran diferencia. Podríamos escribir un libro completo al respecto. Sin embargo, le daré algunas "mejores prácticas":

Use "POST" para cuando su solicitud HTTP cambie algo "concreto" dentro del servidor web. Es decir, está editando una página, creando un nuevo registro, y así sucesivamente. Es menos probable que los POSTS se almacenen en caché, o se traten como algo que es "repetible sin efectos secundarios"

Use "GET" para cuando quiere "mirar un objeto". Ahora, esa apariencia podría cambiar algo "detrás de escena" en términos de almacenamiento en caché o registro, pero no debería cambiar nada "sustancial". Es decir, podría repetir mi GET una y otra vez y no pasaría nada malo, a excepción de los recuentos de aciertos inflados. Los GET deben ser fácilmente marcables, por lo que un usuario puede volver a ese mismo objeto más adelante.

Los parámetros para el GET (el material después del?, Tradicionalmente) se deben considerar "atributos de la vista" o "qué ver" y así sucesivamente. De nuevo, en realidad no debería cambiar nada: use POST para eso.

Y, una última palabra, cuando publique algo (por ejemplo, se está creando un nuevo comentario), tienen el procesamiento para la emisión posterior de un 302 a "redirigir" al usuario a una nueva dirección URL que ve ese objeto . Es decir, un POST procesa la información, luego redirige el navegador a una declaración GET para ver el nuevo estado. Mostrar información como resultado de un POST también puede causar problemas. Hacer la redirección a menudo se usa y hace que las cosas funcionen mejor.