Mezcla GET con POST: ¿es una mala práctica?

Question

¿Es una mala práctica mezclar GET y POST? (tenga en cuenta que esto es en PHP)

p.

<form action="delete.php?l=en&r=homepage" method="post"> 
<!-- post fields here --> 
</form> 

Answer 1

En realidad, esto va a enviar una solicitud de petición POST al servidor, por lo que técnicamente no están mezclando los dos juntos: está utilizando POST con parámetros de URL. No hay nada fundamentalmente erróneo en esto, siempre y cuando no use su URL para los parámetros que deberían tener el formato de campo oculto.

Existen reglas simples: se usa GET (posiblemente con parámetros de URL) para cosas constantes que no cambian el servidor, y POST para lo que modifica el servidor. Si los parámetros de tu url contenían la ID de algo que querías eliminar, sería una mala práctica.

EDITAR, años más tarde

me pidieron para la fuente, así que aquí están la parte pertinente de la misma especificación de HTTP

http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html

se ha establecido la convención de que la GET y los métodos HEAD NO DEBERÍAN tener la importancia de tomar una acción que no sea la recuperación. Estos métodos deben considerarse "seguros". Esto permite a los agentes de usuario representar otros métodos, como POST, PUT y DELETE, de forma especial, para que el usuario tenga conocimiento del hecho de que se está solicitando una acción posiblemente insegura.

Ahí va, GET no debe cambiar nada, POST es para algo que cambie el servidor (operación insegura). Debería poder llamar a GET cualquier cantidad de tiempo. Es más que idempotente: debe ser (en la medida de lo posible) libre de efectos secundarios. Con GET, la solicitud puede no llegar al servidor si está involucrado el almacenamiento en caché.

Así que sí: ¿tiene un formulario, desea saber si utiliza GET o POST? Luego cambie server => POST, no cambie server => GET. Y como se puede acceder a una URL con cualquier verbo (get o post), no coloque los datos que cambian el servidor en la URL, porque alguien puede copiar esa URL, hacer un GET y cambiar su servidor sin que usted lo sepa. Imagine qué pasaría si alguien copiara esa URL en Facebook y 10 000 personas comenzaran a borrar cosas al azar. No está bien. El framework reciente (node, ruby) está mejor aislado contra eso, pero no es básico PHP, por lo que es una buena regla general para ese lenguaje.

Answer 2

Sigue siendo un POST, solo está incluyendo una cadena de consulta en la URL. No veo un problema con esto. Esto es probablemente más limpio que incluir esas variables en los datos de publicación mediante el uso de campos de entrada ocultos. Además, en el servidor, probablemente no desee el valor de l (¿idioma?) Con sus datos de publicación. Si siempre está en la cadena de consulta, puede usar el mismo código que en otro lugar para determinar el idioma, en lugar de tener un caso especial para las solicitudes POST.

Answer 3

No, esto está bien. Hago exactamente esto en el sitio web de mi compañía, por ejemplo en la página de administración del usuario.La URL normal es:

/admin/user?name=jkugelman 

continuación para eliminar un usuario que publico a esta misma página, salvo que publico una variable en vez de hacer un GET, ya que la eliminación se aplican una acción de estado y debe hacerse con un POST. Se ve algo como esto:

<!-- Post back to self --> 
<form action="/admin/user?name=jkugelman"> 
    <input type="submit" name="delete" value="Delete" 
      onchange="return confirm('Are you sure?')" /> 
</form>