HTTP GET y POST recomendaciones parámetros

Question

¿Es una mala práctica de emitir la petición POST siguiente:

/test?a=1&b=2 
POST data: c=3&d=4 

en cuenta que 2 parámetros son parte de la URL y 2 parámetros son parte del contenido de la entrada.

Por otro lado, es la siguiente regla todavía se recomienda: solicitud

• GET: recuperar el contenido de el servidor, pero no cambia nada en el servidor.
• solicitud POST: publicar contenido al servidor que puede modificar datos en el servidor

Me pregunto porque veo un poco de todo en línea.

Laurent Luce

Answer 1

Sí, sus suposiciones son correctas. Debe ser coherente en la forma en que pasa sus parámetros o requiere que se pasen los parámetros, pero realmente no va a hacer ningún daño.

Las operaciones GET se supone que son operaciones seguras, que no realizan ningún efecto secundario (además del almacenamiento en caché, etc.), por lo que se almacenan fácilmente en caché por proxies y demás. Las operaciones de POST por otro lado pueden encerrar efectos secundarios.

Yo recomendaría leer el Wikipedia entry on HTTP protocol:

GET

Solicitudes una representación del recurso especificado. Tenga en cuenta que GET no debe usarse para operaciones que causan efectos secundarios, como su uso para realizar acciones en aplicaciones web. Una razón para esto es que GET puede ser usado arbitrariamente por robots o rastreadores, que no deberían tener que considerar los efectos secundarios que una solicitud debería causar. Vea los métodos seguros a continuación.

la POST

datos somete a ser procesados ​​(por ejemplo, de un formulario HTML) para el recurso identificado. Los datos están incluidos en el cuerpo de la solicitud. Esto puede dar como resultado la creación de un nuevo recurso o las actualizaciones de los recursos existentes o ambos.

También existen otras operaciones (por ejemplo HEAD, PUT, DELETE), y debería considerar usarlas si está diseñando una API. Estos son ampliamente discutidos en el diseño RESTful API.

Answer 2

No hay nada de malo en eso. El motivo por el que se deben enviar los datos de modificación en el POST es que no se volverán a modificar los datos si el usuario hizo clic en el botón Actualizar. En ese caso, solo se enviará la información GET.

Answer 3

Esa regla definitivamente todavía se recomienda.

Se refleja en el comportamiento de actualización de los navegadores modernos. Estos actualizarán felizmente con valores GET, pero mostrarán un cuadro de diálogo de advertencia en una actualización de un POST ("¿estás seguro de que quieres volver a enviar?", Etc.).

Parece que estaba intentando combinar los dos métodos (GET y POST) ...mediante POSTING a una URL con valores GET. Si bien esto debería funcionar bien, no se hace comúnmente. Las formas generalmente usan exclusivamente uno u otro.

Answer 4

Sí, la semántica de GET y POST debe respetarse.

Teniendo en cuenta este hecho, a continuación, a menudo hay una muy buena razón para poner algunos parámetros en el GET y algunos en el POST vars - considerar el caso en el que usted tiene un guión basado en web que hace algo como:

UPDATE datatable SET quantity=30 WHERE order=21559 

Esto podría ser representado como:

/update?order=21559 
POST data: quantity=30 

C.