http - sirven - rest api tutorial español
¿Cuál es la utilidad de los métodos de solicitud PUT y DELETE HTTP? (2)
ELIMINAR es para eliminar el recurso de solicitud:
El método DELETE solicita que el servidor de origen elimine el recurso identificado por Request-URI. Este método PUEDE ser anulado por intervención humana (u otros medios) en el servidor de origen. No se puede garantizar al cliente que la operación se haya 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 URI de solicitud proporcionado. Si el URI de solicitud se refiere a un recurso ya existente, la entidad adjuntada DEBERÍA considerarse como una versión modificada de la que reside en el servidor de origen. Si el URI de solicitud no apunta a un recurso existente, y ese URI es capaz de ser definido como un nuevo recurso por el agente de usuario solicitante, el servidor de origen puede crear el recurso con ese URI ...
Para la visita completa de especificaciones:
Dado que los navegadores actuales lamentablemente no admiten otros verbos que POST y GET en formularios HTML , por lo general no se puede utilizar HTTP en toda su extensión (sin embargo, puede secuestrar su envío a través de JavaScript). La ausencia de soporte para estos métodos en formularios HTML llevó a que los URI contengan verbos, como por ejemplo
POST http://example.com/order/1/delete
o peor
POST http://example.com/deleteOrder/id/1
tunelización efectiva de la semántica CRUD a través de HTTP. Pero los verbos nunca fueron destinados a ser parte de la URI. En cambio, HTTP ya proporciona el mecanismo y la semántica a 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 túnel de datos.
Para eliminar un recurso en el servidor web, llamarías
DELETE http://example.com/order/1
y para actualizarlo llamarías
PUT http://example.com/order/1
y proporcione la Representación de recursos actualizada en el cuerpo 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 , probablemente lo haga enviar solicitudes PUT y DELETE. Este podría ser un cliente creado 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 más detalles, visita:
- http://martinfowler.com/articles/richardsonMaturityModel.html
- ¿Los métodos PUT, DELETE, HEAD, etc. están disponibles en la mayoría de los navegadores web?
- ¿Por qué no hay métodos PUT y DELETE en formularios HTML?
- ¿Deberían usarse 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
He leído muchas cosas sobre esto pero no he podido llegar a la conclusión sobre este tema.
Pero nunca he usado PUT o ELIMINAR métodos de solicitud HTTP. Mi tendencia es utilizar 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?
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 a blogController::articleAction($id); Ahora este enrutador solo conoce la URL o /blog/article/1/
Pero si ese Enrutador conociera todo el objeto Solicitud HTTP en lugar de solo la URL, podría tener acceso al verbo Solicitud HTTP (OBTENER, PUBLICAR, PONER, ELIMINAR ...) 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 dependiendo del verbo HTTP Request.
Por ejemplo:
si quieres recuperar el artículo 1, puedes hacer esto:
GET /blog/article/1 HTTP/1.1
pero si quieres eliminar el artículo 1, harás esto:
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 HTTP Request. Y basado en ese verbo, su enrutador puede llamar a un diferente actionController. Esto le permite construir URL-s ordenadas.
Lea estos dos artículos, pueden ayudarle:
Symfony 2 - Conceptos básicos de HTTP
Estos artículos tratan sobre el marco Symfony 2, pero pueden ayudarlo a determinar cómo funcionan las Solicitudes HTTP y las Respuestas.
¡Espero que esto ayude!