ruby on rails - metodos - ¿Por qué usar los métodos HTTP PUT y DELETE en lugar de POST?

metodos de peticion http

Question

new_story GET     /story/new(.:format)  {:action=>"new", :controller=>"stories"}
edit_story GET     /story/edit(.:format) {:action=>"edit", :controller=>"stories"}
     story GET     /story(.:format)      {:action=>"show", :controller=>"stories"}
           PUT     /story(.:format)      {:action=>"update", :controller=>"stories"}
           DELETE  /story(.:format)      {:action=>"destroy", :controller=>"stories"}
           POST    /story(.:format)      {:action=>"create", :controller=>"stories"}

En el trabajo web que he hecho con otras tecnologías, solo he usado los métodos GET y POST. Pero con las rutas RESTful en Rails, de forma predeterminada, los métodos PUT y DELETE se utilizan para las acciones de actualización y destrucción. ¿Cuál es la ventaja o la necesidad de usar PUT y DELETE? Supongo que estos métodos son solo otra forma de hacer POST, pero ¿por qué no seguir con POST?

Answer 1

Aquí está la sección de "métodos" de la especificación HTTP 1.1 ; define muchos métodos y todos tienen diferentes beneficios y concesiones. POST es la más flexible, pero las compensaciones son numerosas: no se puede almacenar en caché (por lo que el resto de Internet no puede ayudarlo a escalar), no es seguro ni es idempotente, por lo que el cliente no puede reenviarlo solo si recibe un error. y ya no está claro exactamente lo que estás intentando lograr (porque es muy flexible). Estoy seguro de que hay otros pero eso debería ser suficiente. Dado todo esto, si la especificación HTTP define un método que hace exactamente lo que usted desea que haga su solicitud, no hay razón para enviar un POST lugar.

La razón por la cual POST es tan común es que, históricamente al menos, los navegadores web solo admiten GET y POST . Dado que GET se define como seguro e idempotente (aunque muchas aplicaciones no se adhieren a eso), la única forma segura de modificar los datos era enviar un POST . Con el auge de los clientes AJAX y no navegadores, eso ya no es cierto.

Por cierto, el mapeo que dio @mipadi es el mapeo estándar, pero no es el único válido. Amazon S3, por ejemplo, usa PUT para crear recursos. La única razón para usar POST es si el cliente no tiene el conocimiento suficiente para crear el recurso, por ejemplo, respalda sus recursos con una base de datos relacional y usa claves sustitutas artificiales.

Answer 2

Eso sería algo así como preguntar por qué "eliminar" un archivo cuando solo se puede configurar su contenido a cero bytes y el sistema de archivos simplemente lo trataría como una eliminación. HTTP ha soportado verbos distintos de GET / POST para siempre, pero la forma en que SOAP evolucionó torció el significado original de esos verbos. REST es un enfoque más simple, de vuelta a lo básico, que utiliza los verbos como se pretendían, en lugar de inventar un nuevo concepto de verbo dentro de la carga útil.

Answer 3

La ventaja es principalmente semántica, y también puede simplificar las URL en cierta medida. Los diferentes métodos HTTP se asignan a diferentes acciones:

POST   => create a new object
DELETE => delete an object
PUT    => modify an object
GET    => view an object

Entonces, en teoría, puedes usar la misma URL, pero interactuar con ella usando diferentes métodos; El método utilizado para acceder al recurso define el tipo real de operación.

Sin embargo, en la práctica, la mayoría de los navegadores solo admiten HTTP GET y POST. Rails utiliza algunos "trucos" en los formularios HTML para actuar como si se hubiera enviado una solicitud PUT o DELETE, aunque Rails todavía esté utilizando GET o POST para estos métodos. (Esto explica por qué es posible que no haya utilizado DELETE o PUT en otras plataformas).

Answer 4

Solo quería agregar algo a la respuesta aceptada porque su definición de los http verbs es incorrecta. Todos tienen una especificación que debe "seguirse" y usted puede crear / actualizar / eliminar con múltiples http verbs basados ​​en las especificaciones.

Voy a resaltar algunos de los bits importantes en el RFC 2616 por W3

Voy a comenzar con PUT porque, en mi opinión, tiene la mayor confusión que lo rodea.

• PUT is used for both create/update PUT updates by completely replacing the resource on the server with the resource sent in the request

Por ejemplo

Haces esta llamada a mi api

PUT        /api/person
{
     Name: John,
     email: [email protected]
}

mi servidor tiene este recurso viviendo en el servidor

{
     Name: Jane,
     email: [email protected]
}

Ahora mi recurso existente es reemplazado completamente por lo que me enviaste y esto es lo que tengo en mi servidor.

{
     Name: John,
     email: [email protected]
}

Así que si PUT y solo envías un correo electrónico en el cuerpo.

PUT        /api/person
{
     email: [email protected]
}

Mi servidor reemplazará completamente a la entidad

{
     Name: Jane,
     email: [email protected]
}

Con

{
     email: [email protected]
}

Y el nombre se habrá ido. Las actualizaciones parciales son para PATCH pero yo uso POST para eso de todos modos.

• One of the main reasons why we create/update with put is because it is idempotent.

Es solo un término sofisticado y la definición básica es que múltiples solicitudes idénticas son las mismas para una sola solicitud.

Ejemplo

Supongamos que PUEDO PUT un archivo a api/file si el servidor de origen no encuentra ese archivo, creará uno. Si encuentra un archivo, reemplazará completamente el archivo antiguo con el que envié. Esto asegura que un archivo se cree y se actualice. Si no existe ningún archivo y usted llama PUT 5 veces, la primera vez que crea un archivo, las otras 4 veces reemplaza el archivo con lo que envía. Si llama a un POST 5 veces para crearlo, se crearán 5 archivos.

• You PUT to that exact URI. If you don''t you have to send a 301 (Moved Permanently) to the user and allow then make a choice whether or not to redirect the request. Most times the server you PUT to usually hosts the resource and takes care of updating it

Esos son los puntos principales en cuándo usar PUT

En lo que se refiere a POST

• You can also create/update and then some...

Como mencioné anteriormente, hay algunas diferencias clave.

• El post es más general. ¿De qué maneras? algunos otros ejemplos incluyen una puerta de enlace a otros protocolos, podría tomar la respuesta y enviarla a algún manejador de datos en el medio de la noche, o puede extender algún tipo de funcionalidad.
• La publicación no tiene la restricción de "Para el URI o la notificación exactos", por ejemplo, POST puede agregar un recurso a una colección existente y decidir dónde se almacena.

Ahora, ¿qué hay de Delete ? ¿Por qué no acabo de POST ?

Al DELETE , el servidor NO DEBE responder con éxito a menos que elimine el recurso o lo mueva a una ubicación inaccesible en el momento en que se envía la respuesta .

¿Por qué es eso importante? ¿Qué DELETE si llama DELETE pero el recurso tiene que pasar por "APROBACIÓN" antes de ser eliminado? Si se puede rechazar la eliminación, no puede enviar un código de error exitoso y si sigue las especificaciones básicas de esto, es confuso para la persona que llama. Sólo un ejemplo, estoy seguro de que puedes pensar en muchos otros.

Acabo de resaltar algunos de los puntos principales sobre cuándo usar los Http verbs comunes de Http verbs