GET (y algunos otros métodos) se definen como 'SEGUROS' en la especificación http ( RFC 2616 ):
9.1.1 Métodos seguros
Los implementadores deben tener en cuenta que el software representa al usuario en
sus interacciones a través de Internet, y deben tener cuidado de permitir
el usuario debe ser consciente de cualquier acción que pueda tomar que pueda tener una
significado inesperado para ellos mismos u otros.
En particular, se ha establecido la convención de que el GET y
Los métodos de HEAD NO DEBEN tener el significado de tomar una acción
Aparte de la recuperación. Estos métodos deben considerarse "seguros".
Esto permite a los agentes de usuario representar otros métodos, como POST, PUT
y BORRAR, de una manera especial, para que el usuario tenga conocimiento de la
hecho de que se está solicitando una acción posiblemente insegura.
Naturalmente, no es posible garantizar que el servidor no lo haga
generar efectos secundarios como resultado de realizar una solicitud GET; en
De hecho, algunos recursos dinámicos consideran que una característica. Lo importante
La distinción aquí es que el usuario no solicitó los efectos secundarios, por lo que
por lo tanto, no puede ser responsabilizado por ellos.
Esto significa que una solicitud GET nunca debe tener consecuencias graves para el usuario, más allá de ver algo que no desea ver, pero una solicitud POST podría cambiar un recurso que es importante para ellos o para otras personas.
Aunque esto ha cambiado con JavaScript, tradicionalmente había diferentes interfaces de usuario: los usuarios podían activar solicitudes GET haciendo clic en los enlaces, pero tendrían que rellenar un formulario para activar una solicitud POST. Creo que los diseñadores de HTTP estaban dispuestos a mantener la distinción entre métodos seguros y no seguros.
También creo que nunca debería ser necesario redirigir a un POST. Cualquier acción que deba llevarse a cabo se puede realizar presumiblemente llamando a una función dentro del código del lado del servidor, o si tiene que suceder en un servidor diferente, en lugar de enviar un redireccionamiento que contenga una URL para que el navegador publique, el servidor podría realizar una solicitud a ese servidor en sí mismo, actuando como un proxy para el usuario.