¿Cuál es la ventaja práctica de utilizar HTTP GET, PUT, DELETE, POST, HEAD? ¿Por qué no enfocarse en sus beneficios de comportamiento (seguridad e idempotencia), olvidando sus nombres, y usar GET, PUT o POST dependiendo del comportamiento que queramos?¿Por qué necesitamos algo más que HTTP GET, PUT, POST?
¿Por qué no deberíamos usar GET, PUT y POST (y soltar HEAD, DELETE)?
El enfoque [REST] [1] utiliza POST, GET, PUT y DELETE para implementar las reglas CRUD para un recurso web. Es una forma simple y ordenada de exponer objetos a las solicitudes en la web. Son servicios web sin los gastos generales.
Solo para aclarar las diferencias semánticas. Cada operación es bastante diferente. El punto es tener buenos métodos HTTP que tengan significados claros y distintos.
POST crea objetos nuevos. El URI no tiene clave; acepta un cuerpo de mensaje que define el objeto. Insertar SQL. [Editar Si bien no hay ninguna razón técnica para POST a tener ninguna tecla, la gente REST sugieren fuertemente que la POST de tener distinto significado que CREAR, no debe tener una clave.]
GET recupera los objetos existentes. El URI puede tener una clave, depende de si está haciendo singleton GET o list GET. SQL Select
PUT actualiza un objeto existente. El URI tiene una clave; Acepta un cuerpo de mensaje que actualiza un objeto. Actualización de SQL.
ELIMINAR elimina un objeto existente. El URI tiene una clave. SQL Delete.
¿Se puede actualizar un registro con POST en lugar de PUT? No sin introducir alguna ambigüedad. Los verbos deben tener efectos inequívocos. Además, POST URI no tienen clave, donde PUT debe tener una clave.
Cuando PUBLICO, espero un 201 CREADO. Si no entiendo, algo está mal. Del mismo modo, cuando PONGO, espero un 200 OK. Si no entiendo, algo está mal.
Supongo que podría insistir en cierta ambigüedad donde POST hace POST o PUT. El URI debe ser diferente; también el mensaje asociado podría ser diferente. En general, los usuarios de REST siguen el ejemplo de SQL, donde INSERT y UPDATE son verbos diferentes.
Puede indicar que UPDATE debe insertarse si el registro no existe o actualizar si el registro existe. Sin embargo, es más simple si ACTUALIZAR significa ACTUALIZAR y no actualizar significa que algo anda mal. Un repliegue secreto de INSERT hace que la operación sea ambigua.
Si no está construyendo una interfaz RESTful, entonces es típico usar solo GET y POST para recuperar y crear/actualizar. Es común tener diferencias de URI o diferencias de contenido de mensaje para distinguir entre POST y PUT cuando una persona hace clic en enviar en un formulario. Sin embargo, no está muy limpio porque su código tiene que determinar si está en el caso POST = crear caso o POST = actualizar.
Sí, pero eso no responde mi pregunta. Estaba preguntando por qué incluso te molestaría usar PUT, DELETE cuando GET, POST hará el trabajo bien? ¿A quién le importa cómo se llaman si el comportamiento es el mismo? – Gili
El comportamiento no es el mismo. PUT no es lo mismo que POST. PUT corresponde a la actualización, POST corresponde a crear. La semántica es completamente diferente. –
No veo ninguna razón técnica por la cual no puedas actualizar un registro usando POST. Puede haber una convención que diga que debes usar uno u otro, pero a nivel técnico no creo que haga la diferencia. – Gili
¿Por qué necesitamos más que POST? Permite que los datos fluyan en ambos sentidos, entonces, ¿por qué se necesitaría GET? La respuesta es básicamente la misma que tu pregunta. Al estandarizar las expectativas básicas de los diversos métodos, otros procesos pueden saber mejor qué hacer.
Por ejemplo, los proxies intermedios de caché pueden tener una mejor oportunidad de hacer lo correcto.
Piensa en HEAD por ejemplo. Si el servidor proxy sabe lo que significa HEAD, entonces puede procesar el resultado de una solicitud GET anterior para proporcionar la respuesta adecuada a una solicitud HEAD. Y puede saber que POST, PUT y DELETE no deben almacenarse en caché.
Sospecho que HTTP POST hace que los servidores proxy vuelquen cualquier entrada en caché asociada con esa URL (pero no puedo encontrar esto discutido de ninguna manera en la especificación HTTP). Si esto es cierto, ¿POST no reemplaza PUT y DELETE? – Gili
De acuerdo con la especificación, según lo recuerdo: OBTENER - buscar datos. PUT - envía datos, que deberían ser accesibles en el futuro. POST - envía datos a un "programa" y obtiene una respuesta. Un caché probablemente se diseñará para que coincida con estas definiciones. – Darron
No todos los hosters no admiten PUT, DELETE.
hice esta pregunta, en un mundo ideal tendríamos todos los verbos, pero ....:
Para limitar la ambigüedad que permitirá una mejor/más fácil reutilización de nuestro simple REST Apis.
Puede usar solo GET y POST, pero luego está perdiendo parte de la precisión y claridad que traen PUT y DELETE. POST es una operación comodín que podría significar cualquier cosa. El comportamiento de PUT y DELETE está muy bien definido. Si piensa en una API de gestión de recursos, entonces GET, PUT y DELETE probablemente cubran el 80% -90% de la funcionalidad requerida. Si se limita a GET y POST, se accede al 40% -60% de su API con el POST mal especificado.
La guerra del servidor web de los primeros días probablemente lo causó.
En HTTP 1.0 written in 1996, there were only GET, HEAD, and POST. Pero como puede ver en Appendix D, los vendedores comenzaron a agregar sus propias cosas. Por lo tanto, para mantener HTTP compatible, se vieron obligados a hacer HTTP 1.1 in 1999.
Sin embargo, HTTP/1.0 no tiene suficientemente en cuenta los efectos de proxies jerárquicos, el almacenamiento en caché, la necesidad de conexiones persistentes o hosts virtuales. Además, la proliferación de aplicaciones implementadas de forma incompleta llamándose a sí mismas "HTTP/1.0" ha necesitado un cambio de versión de protocolo para dos aplicaciones de comunicación para determinar las capacidades reales de los demás.
Esta especificación define el protocolo denominado "HTTP/1.1". Este protocolo incluye requisitos más estrictos que HTTP/1.0 en orden para garantizar la implementación confiable de sus características.
Las aplicaciones web que utilizan GET y POST permiten a los usuarios crear, ver, modificar y eliminar sus datos, pero lo hacen en una capa encima de los comandos HTTP creados originalmente para estos fines. Una de las ideas detrás de REST es el retorno a la intención original del diseño de la Web, por el cual hay operaciones HTTP específicas para cada verbo CRUD.
Además, el comando HEAD se puede utilizar para mejorar la experiencia del usuario para descargas de archivos (potencialmente grandes). Llame a HEAD para averiguar qué tan grande será la respuesta y luego llame a GET para recuperar el contenido.
Consulte el siguiente link para un ejemplo ilustrativo. También sugiere una forma de utilizar el método OPTIONS http, que aún no se ha discutido aquí.
GET, PUT, DELETE y POST son vestigios de una era en la que los estudiantes de segundo año pensaban que una página web podría reducirse a unos pocos principios de la novena edad.
Hoy en día, la mayoría de las páginas web son entidades compuestas, que contienen algunas o todas estas operaciones primitivas.Por ejemplo, una página puede tener formularios para ver o actualizar la información del cliente, que tal vez abarque varias tablas.
lo general el uso $ _REQUEST [] en php, no es realmente el cuidado de cómo llegó la información. Yo elegiría usar métodos GET o PUT basados en la eficiencia, no en los paradigmas subyacentes (múltiples).
alguien quiere explicarse? Soy curioso. – dar7yl
¿Estás preguntando sobre el voto negativo? –
Sí, (podría haber respondido sin este protocolo) Mi punto es que la mayoría de las páginas web no se ajustan al paradigma ideal, y las diferencias GET y PUT ni siquiera se pueden aplicar, por lo que el concepto subyacente es defectuoso. – dar7yl
POST no tiene garantías de safety or idempotency. Esa es una razón para PUT y DELETE -tanto PUT y DELETE son idempotente (es decir, 1 + N solicitudes idénticas tienen el mismo resultado final como se acaba de 1 petición).
PUT se usa para configuración el estado de un recurso en un URI determinado. Cuando se envía una solicitud dePOST a un recurso en un determinado URI, ese recurso no debería ser reemplazado por el contenido. A lo sumo, debe ser anexado a. Esta es la razón por la que POST no es idempotente: en el caso de agregar POSTS, cada solicitud se agregará al recurso (por ejemplo, publicar un mensaje nuevo en un foro de discusión cada vez).
DELETE se utiliza para asegurarse de que un recurso a un determinado URI se elimina del servidor. POSTAL normalmente no debe ser utilizado para borrar excepto para el caso de la presentación de una solicitud para eliminar. Una vez más, el URI del recurso que usted POSTARÍA en ese caso no debería ser el URI para el recurso que desea eliminar. Cualquier recurso para el que realiza la POST to es un recurso que acepta los datos POSTed para anexarse a sí mismo, agregar a una colección o procesar de alguna otra manera.
HEAD se utiliza si todo lo que le interesa son los encabezados de una solicitud GET y no desea perder ancho de banda en el contenido real. Esto es bueno tener
Nadie registró el tipo de respuesta que estaba buscando así que voy a tratar de resumir los puntos mí mismo. "RESTful Web Services" capítulo 8 sección "Overloading POST" dice: "Si quiere prescindir de PUT y DELETE por completo, es completamente RESTful exponer operaciones seguras en recursos a través de GET y todas las demás operaciones a través de POST sobrecargado. Hacer esto viola mi Arquitectura Orientada a Recursos, pero se ajusta a las reglas menos restrictivas de REST ".
En resumen, reemplazando PUT/DELETE a favor de POST hace que la API sea más difícil de leer y las llamadas PUT/DELETE ya no son idempotentes.
Hay extensiones http como WebDAV que requieren funcionalidades adicionales.
En una palabra:
idempotencia
En unas pocas palabras más:
GET = segura + idempotente
PUT = idempotente
DELETE = idempotente
post = ni seguro o idempotente
'idempotente' sólo significa que puede hacerlo una y otra vez y siempre va a hacer exactamente lo mismo.
Puede volver a emitir una solicitud PUT (update) o DELETE tantas veces como desee y tendrá el mismo efecto siempre, sin embargo, el efecto deseado modificará un recurso por lo que no se considera 'seguro'.
Una solicitud POST debe crear un nuevo recurso con cada solicitud, lo que significa que el efecto será diferente cada vez. Por lo tanto, POST no se considera seguro ni idempotente.
Los métodos como GET y HEAD son solo operaciones de lectura y, por lo tanto, se consideran "seguros" e idempotentes.
Esto es realmente un concepto bastante importante porque proporciona una forma estándar/consistente de interpretar las transacciones HTTP; esto es particularmente útil en un contexto de seguridad.
Entonces mi punto se convierte entonces, ¿por qué no enfocarse en las diversas categorías en lugar del nombre del método? 1) Cuando desee un idempotente seguro, solo use GET, eliminando HEAD. 2) Cuando desee idempotent solo use PUT, eliminando DELETE. 3) Cuando lo desee, tampoco use POST. – Gili
HEAD es realmente útil para determinar el reloj de un servidor determinado (con una precisión de 1 segundo o el tiempo de ida y vuelta de la red, el que sea mayor). También es ideal para obtener cotizaciones de Futurama Slashdot:
~$ curl -I slashdot.org HTTP/1.1 200 OK Date: Wed, 29 Oct 2008 05:35:13 GMT Server: Apache/1.3.41 (Unix) mod_perl/1.31-rc4 SLASH_LOG_DATA: shtml X-Powered-By: Slash 2.005001227 X-Fry: That's a chick show. I prefer programs of the genre: World's Blankiest Blank. Cache-Control: private Pragma: private Connection: close Content-Type: text/html; charset=iso-8859-1
Para cURL, -I es la opción para realizar una petición HEAD. Para obtener la fecha actual y la hora de un servidor determinado, acaba de hacer
curl -I $server | grep ^Date
¿Estás sugiriendo utilizar sólo GET y POST? No pude entenderlo. – Till
Gracias por señalar esto, he aclarado la pregunta. – Gili
Gili, debajo de ti ahora también quieres tirar PUT. Creo que necesitas volver a escribir la pregunta desde cero. La web parece funcionar con GET y POST, por lo que tal vez sea suficiente. – pbreitenbach