He leído un montón de cosas acerca de esto, pero no es capaz de llegar a la conclusión sobre este tema.

Pero nunca la he utilizado PUT o DELETE HTTP métodos de Petición. Mi tendencia es a utilizar OBTIENE cuando stat del sistema(mi aplicación o sitio web), no pueden ser afectados (como producto de la lista) y el uso de POST cuando es afectado(pedido). ¿No es suficiente o me estoy perdiendo algo ?

  • PUT/DELETE es más fácil de código, pero más difícil de la instalación (en materia de seguridad – vhost/apache directory). Mi humilde opinión… se puede vivir sin ellos.
  • sí, estoy extremadamente feliz sin ellos 🙂 pero necesito alguna respuesta sobre por qué están allí ?? he leído algunas cosas, pero no podía cop es
InformationsquelleAutor Rupesh Patel | 2012-08-27

3 Comentarios

  1. 82

    DELETE para eliminar la solicitud de recursos:

    El método DELETE peticiones que el servidor de origen, de eliminar el recurso identificado por el URI de la Solicitud. Este método PUEDE ser reemplazado por la intervención humana (u otros medios) en el servidor de origen. El cliente no se puede garantizar que la operación ha sido llevada a cabo, incluso si el código de estado devuelto desde el servidor de origen indica que la acción se ha completado con éxito …

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

    El método PUT solicita que la entidad se almacenan bajo la suministra el URI de la Solicitud. Si el URI de la Solicitud se refiere a una ya existente de recursos, la entidad DEBE ser considerada como una versión modificada de la que reside en el servidor de origen. Si el URI de la Solicitud no apunta a un recurso existente, y que URI es capaz de ser definido como un nuevo recurso por el que solicita agente de usuario, el servidor de origen puede crear el recurso con que URI …

    Para la especificación completa visita:

    Desde los navegadores actuales por desgracia, no se admite ningún otro de los verbos de POST y GET en los formularios HTML, normalmente no se puede utilizar HTTP a la medida con ellos (todavía se puede secuestrar su envío a través de JavaScript, aunque). La ausencia de apoyo para estos métodos en los formularios HTML llevó a Uri que contiene los verbos, como por ejemplo

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

    o incluso peor

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

    efectivamente túnel CRUD semántica a través de HTTP. Pero los verbos no estaban destinadas a ser parte de la URI. En lugar de HTTP, ya ofrece el mecanismo y la semántica para CRUD de un Recurso (por ejemplo, una orden) a través de los métodos HTTP. HTTP es un protocolo y no sólo algunos datos de túnel de servicio.

    Para eliminar un Recurso en el servidor web, que se llama

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

    y a la actualización de lo que se llama

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

    y proporcionar la actualización de la Representación de Recurso en el cuerpo para que el servidor web a aplicar a continuación.

    Por lo tanto, si usted está construyendo una especie de cliente para un LA API DE REST., que es probable que hacer es enviar solicitudes PUT y DELETE. Esto podría ser un cliente construido dentro de un navegador, por ejemplo, el envío de solicitudes a través de JavaScript o podría ser alguna herramienta que se ejecuta en un servidor, etc.

    Para más detalles visite:

    • Los navegadores puede enviar PUT y DELETE con JavaScript!
    • Sí, pero formulario HTML métodos no. Y mientras que no es compatible con la de la caja, tienes que ir a través de aros para hacer que funcione. Es uno de los principales fallos de los fabricantes de los navegadores.
    • Por supuesto que no, los formularios diseñados por POST y GET. Que es en el diseño HTML. Esto no es cierto decir que PUT y DELETE no es compatible, aunque. Implementar los navegadores HTML y HTTP.
    • estamos, probablemente, no tengan la misma definición de «apoyos» de entonces. La mayoría de los Navegadores apoyo JavaScript y, sí, JavaScript se pueden hacer peticiones HTTP, pero todavía tengo que programa que, enlazar el código a algunos elementos de interfaz de usuario y se la entregará al cliente en primer lugar.
    • El navegador muestra una página en blanco a menos que escriba algo de HTML. Sí, tal vez tenemos que estar en desacuerdo. En desacuerdo está bien!
    • Volvía a repetir partes de la respuesta. Espero que sea más claro ahora.
    • Entonces, ¿qué hay de malo con cosas como poner una «eliminar», el verbo en la URL? He visto Api, como el Telegrama, donde no les importa en absoluto el método que usted utilice. Hace las cosas menos confuso si nada, porque entonces nunca hay un URL a hacer cosas diferentes, basándose en el método. Y no siempre se pueden clasificar a su servicio como CRUD.
    • HTTP es un protocolo y ha semántica y reglas. Seguro, usted puede utilizar willynilly, pero luego que no se adhieren al protocolo. Podría hacer las cosas menos confuso para usted, pero esto hará que sea mucho más confuso para alguien confiando y esperando a su aplicación a adherirse al protocolo. Imagina que decir Adiós en lugar de Hola cuando entras en una habitación. La gente va a pensar que es extraño.
    • pero todavía meanless…todavía se puede utilizar un método post que eliminar un recurso, y usted todavía tiene a la programación de código de servidor acerca de cómo ese recurso sería eliminado/patched, ¿verdad? así que…¿esto es sólo una fantasía modo de hacer peticiones?
    • no es ni fantasía, ni de sentido. Es el prescrito y acordado manera de hacer las cosas cuando se utiliza el protocolo HTTP.
    • Por ejemplo, ELIMINAR puede hacer cosas como invalidar las versiones en caché de la URI. Con un POST basado en la API, cualquier proxy que uso tiene que saber cuál es su API (malo) o desactivarse por completo (los malos). Y es por eso que con las normas de uso. 🙂 (Aunque me gustaría es cierto que ser bueno si formas había una manera de enlazar ELIMINAR a un botón de enviar.)

  2. 23

    Mediante Solicitud HTTP verbo como GET, POST, DELETE, PONER etc… permite crear aplicaciones web RESTful. Leer sobre ello aquí: http://en.wikipedia.org/wiki/Representational_state_transfer

    La forma más sencilla de ver los beneficios de esto es ver en este ejemplo.
    Cada MVC framework tiene un Router/Dispatcher que los mapas de URL-s a actionControllers.
    Así URL como esta: /blog/article/1 invocan blogController::articleAction($id);
    Ahora este Router sólo es consciente de la URL o /blog/article/1/

    Pero si el Router se daría cuenta de todo objeto de Solicitud HTTP en lugar de simplemente URL, él podría tener acceso a la Solicitud HTTP verbo (GET, POST, PUT, DELETE…), y muchas otras cosas útiles acerca de la actual Solicitud HTTP.

    Que le permiten configurar la aplicación para que pueda aceptar la misma URL y el mapa a diferentes actionControllers dependiendo de la Petición HTTP verbo.

    Por ejemplo:

    si quieres recupero el artículo 1, usted puede hacer esto:

    GET /blog/article/1 HTTP/1.1
    

    pero si desea eliminar el artículo 1, que va a hacer esto:

    DELETE /blog/article/1 HTTP/1.1
    

    Observe que ambas Solicitudes HTTP que tienen el mismo URI, /blog/artículo/1, la única diferencia es que la Petición HTTP verbo. Y se basa en que el verbo de su router puede llamar a diferentes actionController. Esto le permite construir limpio URL-s.

    Leer estos dos artículos, que podría ayudar:

    Symfony 2 – HTTP Fundamentos

    Symfony 2 – Enrutamiento

    Estos artículos son sobre Symfony 2 marco de referencia, pero que puede ayudar a averiguar cómo hace las Solicitudes y Respuestas HTTP trabajo.

    Espero que esto ayude!

    • aunque no soy amigo de ellos, muy bien explicado +1 😉
    • Esta respuesta se explica la mejor manera de describir la importancia de los verbos HTTP y se mantenga en línea con los verdaderamente servicios RESTful y sus beneficios. Si no dicen una HTTP ELIMINAR, entonces usted podría tener (2) colocar acciones en el controlador: 1 para Create y 1 para Delete. Si usted hace esto, su muy próxima búsqueda para «¿Cómo tener varios Post de acciones en un solo controlador» :P. No es que esto es horrible, pero perder la capacidad de tener un recurso único ser implementado a través de la acción del verbo en lugar de tener que proporcionar explícitamente el nombre de la acción en la URI.
  3. 1

    Métodos seguros : Obtener Recursos/Ninguna modificación en los recursos

    Idempotente : Ningún cambio en el estado de los recursos si se solicita muchas veces

    Métodos inseguros : Crear o Recursos de Actualización y/o Modificación de los recursos

    No Idempotente : Cambio en el estado de los recursos si se solicita muchas veces

    Según su requisito :

    1) Para la seguridad y operación idempotente (Recuperación de Recursos) uso ——— MÉTODO GET

    2) Por la falta de seguridad y no idempotente operación (Inserción de Recursos) uso——— MÉTODO POST

    3) Por la falta de seguridad y operación idempotente (Actualización de Recursos) uso——— MÉTODO PUT

    3) Por la falta de seguridad y operación idempotente (Eliminar Recurso) uso——— MÉTODO DELETE

Dejar respuesta

Please enter your comment!
Please enter your name here