Solución:
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 a través de 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?
- ¿Deberían 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 un Router/Dispatcher que asigna URL-s a actionControllers. Entonces URL como esta: /blog/article/1 invocaría blogController::articleAction($id);
Ahora, este enrutador solo conoce 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 corro el riesgo de no ser popular digo no son útiles hoy en día.
Creo que tenían buenas intenciones y eran ú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 manera idempotente.
Las cosas evolucionaron y las URL se volvieron virtuales (consulte reescritura de URL por ejemplo) haciendo que los recursos pierdan 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 el rastro.
Tomemos un ejemplo:
- / api / entity / list / {id} vs GET / api / entity / {id}
- / api / entity / add / {id} vs POST / api / entidad
- / api / entity / edit / {id} vs PUT / api / entity / {id}
- / api / entity / delete / {id} vs ELIMINAR / api / entidad / {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 utilizando la elegante API y tiene que buscar dónde se realiza la llamada de eliminación. Buscarás “api / entidad” y entre los resultados tendrás que ver cuál 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 eliminación de la llamada, solo tiene que buscar “api / entidad / eliminar” y lo encontrará de inmediato.
La creación de una API sin toda la gama de métodos HTTP hace que sea más fácil de consumir y mantener posteriormente.