¿Por qué no podemos usar el método POST para todas las solicitudes? [cerrado]

-2

Se sabe que la información confidencial no debe transmitirse en las solicitudes GET, ya que las solicitudes GET se almacenarán en caché y se deberá utilizar POST.

  • ¿Por qué no podemos usar el método POST para todas las solicitudes e ignorar la solicitud GET?

  • ¿Cuáles serán todas las dificultades / barreras que enfrentaremos si ignoramos el método GET y comenzamos a usar POST exclusivamente?

pregunta jey 21.03.2017 - 07:52
fuente

3 respuestas

5

HTTP tiene diferentes verbos , que tienen diferentes semánticas:

  • GET: no cambia nada del lado del servidor, varios GET con los mismos parámetros deberían obtener la misma respuesta; generalmente, se obtiene un valor de cuenta
  • POST: puede realizar cambios en el servidor, múltiples POST con los mismos parámetros pueden llevar a resultados y respuestas diferentes; por lo general, se agrega una cantidad a una cuenta
  • PUT: puede realizar cambios en el lado del servidor, múltiples PUT con los mismos parámetros deberían conducir al mismo resultado y respuesta, generalmente establecen un valor de cuenta

BORRAR y CABEZA también existen, pero no creo que quieras usarlos aquí.

Como POST no es idempotente, el navegador principal le avisará si envía dos veces la misma solicitud POST que no es deseable en los casos de uso de GET .

De todos modos, encabezados en la solicitud HTTP controla dónde se debe almacenar o no la respuesta en la memoria caché, por lo que es posible solicitar cachés para no mantener las respuestas a las solicitudes GET.

Finalmente, el almacenamiento en caché (en el sentido de los servidores proxy de almacenamiento en caché) no está relacionado con la seguridad. Si no desea que alguien escuche sus solicitudes y respuestas, no debe preocuparse por el almacenamiento en caché, sino usar HTTPS, que garantiza que todo esté correctamente encriptado.

El almacenamiento en caché del navegador es una pregunta diferente, porque entonces puede almacenar las últimas URL en su caché de historial. Por lo tanto, la información confidencial no debe enviarse en la URL , a menos que limpie constantemente el historial cuando cierre su navegador y cierre su navegador cuando haya terminado de navegar por un sitio. Pero el envío en la URL y el envío en una solicitud GET son preguntas diferentes. La autenticación básica HTTP permite pasar las credenciales en los encabezados HTTP de una solicitud GET, lo cual es seguro. Y la autenticación del formulario de inicio de sesión es una solicitud no idempotente (el estado posterior y anterior a la autenticación no es el mismo), por lo que será una solicitud POST por semántica HTTP.

TL / DR: el problema no está en la solicitud GET vs POST. Las reglas de confidencialidad son:

  • siempre use HTTPS
  • nunca pase datos confidenciales en la URL.
respondido por el Serge Ballesta 21.03.2017 - 08:15
fuente
1

Su principal problema es que si intenta recargar una página enviada por una solicitud POST, el navegador generalmente mostrará una advertencia de que podría hacer algo dos veces. Esto no es lo que quiere que ocurra en la mayoría de las páginas que usan solicitudes GET.

    
respondido por el Mike Scott 21.03.2017 - 07:57
fuente
-1

Básicamente, GET se considera como una solicitud de alguna operación o datos,

el envío de datos a través de GET se considera como un parámetro

si tienes una aplicación de blog y cuando solicitas una publicación específica, es posible que tengas que usar get

www.mysite.com/myblogapp?post=12,

ahora que la dirección de su navegador está actualizada, puede compartir la url para esa publicación del blog,  o use el botón Atrás para cargar la última publicación de blog visitada (que no es posible con el método de publicación)

POST se utiliza para enviar grandes cantidades de datos, como datos de formularios, archivos cargados, etc.

    
respondido por el Sajan 21.03.2017 - 09:51
fuente

Lea otras preguntas en las etiquetas