.net - metodos - ¿Cuál es la diferencia entre los métodos HTTP GET, POST, PUT y DELETE?

put http (3)

Pero, ¿cuál es la desventaja si no seguimos esta regla anterior, supongamos que para insertar un registro, utilicé el método GET.

Los motores de búsqueda acceden a sus páginas mediante solicitudes GET, por lo que si lo hiciera, el rastreador de Google podría insertar registros que no deseaba.

A menudo, las personas utilizarán POST para cualquier tipo de solicitud de Ajax, con la acción real en el cuerpo de la solicitud. No hay nada malo en esto, pero la característica está ahí para que la use, por lo que también podría usarla.

Estoy desarrollando el servicio REST WCF y como teóricamente sé cuándo optar por qué propósito.

GET para obtener el recurso
PUT para actualizar
POST para insertar
DELETE para borrar

Pero, ¿cuál es la desventaja si no seguimos esta regla anterior, supongamos que inserte un registro que utilicé el método GET ?

Debido a que el método HTTP GET se especifica como idempotente, una solicitud GET, por especificación, se puede reenviar con la suposición de que no cambiará nada en el servidor. Este no es el caso para un HTTP POST que por especificación puede cambiar el estado de la aplicación que se ejecuta en el servidor.

Entonces, por especificación, uno puede realizar un HTTP GET contra una página N número de veces sin preocuparse de cambiar su estado.

No respetar la especificación puede tener varios resultados no deseados. Por ejemplo, los rastreadores web siguen la solicitud GET para indexar un sitio, pero no POST. Si permitió que una solicitud HTTP GET realice cambios en la base de datos, puede comprender fácilmente la implicación no deseada que puede tener.

Respetar una especificación es como respetar un acuerdo entre su servicio o sitio web y un conjunto de diferentes consumidores que pueden ser navegadores de usuarios normales, pero también otros servicios como los rastreadores web.

Puede crear un sitio que use un GET para insertar un registro, pero también debe esperar que todo lo que esté construido para consumir su sitio funcione suponiendo que está respetando el acuerdo.

Como último ejemplo, los navegadores web advierten a los usuarios cuando intentan actualizar una página a la que llegó una solicitud HTTP POST advirtiendo que algunos datos podrían reenviarse. No obtendrá esa capa de navegadores incorporados de protección si una solicitud HTTP GET llega a la página.

Puede leer más aquí: http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html

Enfrenté una situación en la que debería haber usado el PUT en lugar de GET. Recibí una llamada de inserción de permisos para un tercero (esto era google). Giro una solicitud Ajax GET para llamar a mi Servlet y de su llamada pasó al servicio externo. El servicio externo requirió una cantidad considerable de tiempo para finalizar la solicitud. Mientras tanto, estaba viendo la duplicación de la misma llamada de permiso en los registros de mi servidor. Era un navegador que seguía llamando al servidor diciendo: ¿ya terminaste? ya que es un GET y el navegador puede llamar al servidor tantas veces como sea posible. El navegador siguió el estándar y mi código no. Tuve el problema de no seguir el estándar.