¿Cuál es la utilidad de los métodos de solicitud HTTP PUT y DELETE?

He leído mucho sobre esto, pero no pude llegar a una conclusión sobre este tema.

Pero nunca he usado los métodos PUT o DELETE HTTP Request. Mi tendencia es usar GET cuando las estadísticas del sistema (mi aplicación o sitio web) pueden no verse afectadas (como la lista de productos) y usar POST cuando se ve afectado (pedido realizado). ¿No es suficiente o me falta algo?

DELETE es para eliminar el recurso de solicitud:

El método DELETE solicita que el servidor de origen elimine el recurso identificado por el Request-URI. Este método PUEDE ser anulado por la intervención humana (u otros medios) en el servidor de origen. No se puede garantizar al cliente que la operación se ha llevado a cabo, incluso si el código de estado devuelto por el servidor de origen indica que la acción se ha completado con éxito ...

PUT es para poner o actualizar un recurso en el servidor:

El método PUT solicita que la entidad adjunta se almacene bajo el Request-URI proporcionado. Si el Request-URI se refiere a un recurso ya existente, la entidad adjunta DEBERÍA considerarse como una versión modificada de la que reside en el servidor de origen. Si el Request-URI no apunta a un recurso existente, y ese URI puede ser definido como un nuevo recurso por el agente de usuario solicitante, el servidor de origen puede crear el recurso con ese URI ...

Para conocer las especificaciones completas, visite:

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

Dado que los navegadores actuales, lamentablemente, no admiten ningún otro verbo que POST y GET en formularios HTML , por lo general no puede utilizar HTTP en toda su extensión con ellos (aunque aún puede secuestrar su envío a través de JavaScript). La ausencia de soporte para estos métodos en formularios HTML llevó a URI que contenían verbos, como por ejemplo

POST http://example.com/order/1/delete

o aun peor

POST http://example.com/deleteOrder/id/1

tunelizar eficazmente la semántica CRUD sobre HTTP. Pero los verbos nunca debieron ser parte de la URI. En su lugar, HTTP ya proporciona el mecanismo y la semántica para CRUD un recurso (por ejemplo, un pedido) a través de los métodos HTTP. HTTP es un protocolo y no solo un servicio de tunelización de datos.

Entonces, para eliminar un recurso en el servidor web, llamaría

DELETE http://example.com/order/1

y para actualizarlo llamarías

PUT http://example.com/order/1

y proporcionar la Representación de recursos actualizada en el cuerpo de PUT para que el servidor web la aplique en ese momento.

Por lo tanto, si está creando algún tipo de cliente para una API REST , es probable que haga que envíe solicitudes PUT y DELETE. Esto podría ser un cliente construido dentro de un navegador, por ejemplo, enviando solicitudes a través de JavaScript o podría ser alguna herramienta que se ejecuta en un servidor, etc.

Para obtener más detalles, visite:

• http://martinfowler.com/articles/richardsonMaturityModel.html
• ¿Están los métodos PUT, DELETE, HEAD, etc. disponibles en la mayoría de los navegadores web?
• ¿Por qué no hay métodos PUT y DELETE en los formularios HTML?
• ¿Deben utilizarse PUT y DELETE en los formularios?
• http://amundsen.com/examples/put-delete-forms/
• http://www.quora.com/HTTP/Why-are-PUT-and-DELETE-no-longer-supported-in-HTML5-forms

El uso de verbos HTTP Request como GET, POST, DELETE, PUT, etc. le permite crear aplicaciones web RESTful. Lea sobre esto aquí: http://en.wikipedia.org/wiki/Representational_state_transfer

La forma más fácil de ver los beneficios de esto es mirar este ejemplo. Cada marco MVC tiene una Router/Dispatcherque asigna URL-s a actionControllers. Entonces, URL como esta: /blog/article/1invocaría blogController::articleAction($id); Ahora este enrutador solo es consciente de la URL o/blog/article/1/

Pero si ese enrutador tuviera conocimiento del objeto de solicitud HTTP completo en lugar de solo la URL, podría tener acceso al verbo de solicitud HTTP (GET, POST, PUT, DELETE ...) y muchas otras cosas útiles sobre la solicitud HTTP actual.

Eso le permitiría configurar la aplicación para que pueda aceptar la misma URL y asignarla a diferentes actionControllers según el verbo HTTP Request.

Por ejemplo:

si desea recuperar el artículo 1, puede hacer esto:

GET /blog/article/1 HTTP/1.1

pero si desea eliminar el artículo 1, hará lo siguiente:

DELETE /blog/article/1 HTTP/1.1

Tenga en cuenta que ambas solicitudes HTTP tienen el mismo URI, / blog / article / 1, la única diferencia es el verbo de solicitud HTTP. Y según ese verbo, su enrutador puede llamar a diferentes actionController. Esto le permite crear URL-s ordenadas.

Lea estos dos artículos, pueden ayudarlo:

Symfony 2 - Conceptos básicos de HTTP

Symfony 2 - Enrutamiento

Estos artículos tratan sobre el framework Symfony 2, pero pueden ayudarte a descubrir cómo funcionan las solicitudes y respuestas HTTP.

¡Espero que esto ayude!

Aunque me arriesgo a no ser popular, digo que hoy en día no sirven .

Creo que fueron bien intencionados y útiles en el pasado cuando, por ejemplo, DELETE le dijo al servidor que eliminara el recurso encontrado en la URL proporcionada y PUT (con su hermano PATCH) le dijo al servidor que actualizara de una manera idempotente.

Las cosas evolucionaron y las URL se volvieron virtuales (ver reescritura de URL, por ejemplo) haciendo que los recursos perdieran su significado inicial de carpeta / subforder / archivo real y, por lo tanto, los verbos de acción CRUD cubiertos por los métodos del protocolo HTTP (GET, POST, PUT / PATCH, DELETE) perdieron la pista .

Tomemos un ejemplo:

• / api / entity / list / {id} frente a GET / api / entity / {id}
• / api / entity / add / {id} frente a POST / api / entity
• / api / entity / edit / {id} frente a PUT / api / entity / {id}
• / api / entity / delete / {id} vs DELETE / api / entity / {id}

En el lado izquierdo no está escrito el método HTTP, esencialmente no importa (POST y GET son suficientes) y en el lado derecho se utilizan los métodos HTTP apropiados.

El lado derecho se ve elegante, limpio y profesional. Imagine que ahora tiene que mantener un código que ha estado usando la elegante API y tiene que buscar dónde se realiza la llamada de eliminación. Vas a buscar "api / entidad" y entre los resultados que tendrá que ver que uno está haciendo ELIMINAR. O peor aún, tienes un programador junior que por error cambió PUT con DELETE y como URL es lo mismo sucedió.

En mi opinión, poner el verbo de acción en la URL tiene ventajas sobre el uso del método HTTP apropiado para esa acción, incluso si no es tan elegante. Si desea ver dónde se realiza la llamada de eliminación, solo tiene que buscar "api / entity / delete" y la encontrará de inmediato.

La creación de una API sin toda la variedad de métodos HTTP hace que sea más fácil de consumir y mantener posteriormente

Métodos seguros: Obtener recurso / Sin modificación en el recurso
Idempotente: Sin cambio en el estado del recurso si se solicita muchas veces
Métodos inseguros: Crear o actualizar recurso / Modificación en el recurso
No idempotente: Cambio en el estado del recurso si se solicita muchas veces

Según su requisito:

1) Para una operación segura e idempotente (Obtener recurso) use --------- GET METHOD
2) Para una operación insegura y no idempotente (Insertar recurso) use --------- POST METHOD
3) Para operación insegura e idempotente (Actualizar recurso) use --------- MÉTODO PUT
3) Para operación insegura e idempotente (Eliminar recurso) use --------- MÉTODO DELETE