¿Por qué necesitamos algo más que HTTP GET, PUT, POST?
https://stackoverflow.com/questions/147187
-
02-07-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianPregunta
¿Cuál es el beneficio práctico de usar HTTP GET, PUT, DELETE, POST, HEAD? ¿Por qué no enfocarnos en sus beneficios de comportamiento (seguridad e idempotencia), olvidando sus nombres y usar GET, PUT o POST según el comportamiento que queramos?
¿Por qué no solo deberíamos usar GET, PUT y POST (y soltar HEAD, DELETE)?
Solución
El enfoque [REST] [1] usa POST, GET, PUT y DELETE para implementar las reglas CRUD para un recurso web. Es una forma simple y ordenada de exponer objetos a 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 nuevos objetos. El URI no tiene clave; acepta un cuerpo de mensaje que define el objeto. Insertar SQL. [ Editar Si bien no existe una razón técnica para que POST no tenga clave, la gente de REST sugiere firmemente que para que POST tenga un significado distinto como CREATE, no debería tener una clave.]
GET recupera objetos existentes. El URI may tiene 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 SQL.
DELETE elimina un objeto existente. El URI tiene una clave. Eliminar SQL.
¿Puede actualizar un registro con POST en lugar de PUT? No sin introducir cierta ambigüedad. Los verbos deberían tener efectos inequívocos. Además, POST URI no tiene clave, donde PUT debe tener una clave.
Cuando publico, espero un 201 CREADO. Si no entiendo eso, algo está mal. Del mismo modo, cuando pongo, espero un 200 OK. Si no entiendo eso, algo está mal.
Supongo que podría insistir en cierta ambigüedad donde POST hace POST o PUT. El URI tiene que ser diferente; También el mensaje asociado podría ser diferente. En general, la gente de REST toma su ejemplo de SQL donde INSERT y UPDATE son verbos diferentes.
Podría argumentar que UPDATE debería insertarse si el registro no existe o actualizarse si el registro existe. Sin embargo, es más simple si ACTUALIZACIÓN significa ACTUALIZACIÓN y la falla de actualización significa que algo está mal. Un retroceso secreto a INSERT hace que la operación sea ambigua.
Si no está creando una interfaz RESTful, entonces es típico usar GET y POST para recuperar y crear / actualizar. Es común tener diferencias de URI o diferencias de contenido de mensajes para distinguir entre POST y PUT cuando una persona hace clic en enviar en un formulario. Sin embargo, no es muy limpio porque su código tiene que determinar si está en POST = create case o POST = update case.
Otros consejos
POST no tiene garantías de safety o idempotency . Esa es una razón para PUT y DELETE : tanto PUT como DELETE son idempotentes (es decir, 1 + N solicitudes idénticas tienen el mismo resultado final que solo 1 solicitud).
PUT se usa para configurar el estado de un recurso en un URI dado. Cuando envía una solicitud POST a un recurso en un URI particular, ese recurso no debe ser reemplazado por contenido. Como máximo, debe agregarse a. Esta es la razón por la cual POST no es idempotente: en el caso de agregar POSTS, cada solicitud se agregará al recurso (por ejemplo, publique un mensaje nuevo en un foro de discusión cada vez).
ELIMINAR se utiliza para asegurarse de que un recurso en un URI determinado se elimine del servidor. Normalmente, POST no se debe utilizar para eliminar, excepto en el caso de enviar una solicitud para eliminar. Nuevamente, el URI del recurso al que PUBLICARÍA en ese caso no debería ser el URI del recurso que desea eliminar. Cualquier recurso para el cual usted POST es un recurso que acepta los datos PUBLICADOS para adjuntarse a sí mismo, agregarlos a una colección o procesarlos de alguna otra manera.
HEAD se usa si lo único que le importa son los encabezados de una solicitud GET y no desea desperdiciar ancho de banda en el contenido real. Es bueno tenerlo.
¿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 para su pregunta. Al estandarizar las expectativas básicas de los diversos métodos, otros procesos pueden saber mejor qué hacer.
Por ejemplo, los servidores proxy de almacenamiento en caché pueden tener una mejor oportunidad de hacer lo correcto.
Piensa en HEAD por ejemplo. Si el servidor proxy sabe lo que significa HEAD, 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é.
Nadie publicó el tipo de respuesta que estaba buscando, así que intentaré resumir los puntos yo mismo.
" Servicios web RESTful " capítulo 8, sección "Sobrecarga POST" lee: "" Si quiere prescindir de PUT y DELETE por completo, es completamente RESTANTE 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 los recursos, pero se ajusta a las reglas menos restrictivas de REST. & Quot;
En resumen, reemplazar 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 .
En una palabra:
idempotencia
En pocas palabras más:
GET = safe + idempotent
PUT = idempotent
BORRAR = idempotente
POST = ni seguro ni idempotente
'Idempotent' solo significa que puedes hacerlo una y otra vez y siempre hará exactamente lo mismo.
Puede volver a emitir una solicitud PUT (actualización) o DELETE tantas veces como desee y tendrá el mismo efecto cada vez, sin embargo, el efecto deseado modificará un recurso para que no se considere '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" y también como idempotentes.
Este es realmente un concepto muy importante porque proporciona una forma estándar / consistente de interpretar las transacciones HTTP; Esto es particularmente útil en un contexto de seguridad.
No todos los hosts no admiten PUT, DELETE.
Hice esta pregunta, en un mundo ideal tendríamos todos los verbos pero ...:
HEAD es realmente útil para determinar a qué está configurado 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 genial para obtener citas de Slashdot en Futurama:
~$ 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 solicitud HEAD . Para obtener la fecha y hora actuales de un servidor determinado, simplemente haga lo siguiente:
curl -I $ server | grep ^ Fecha
Para limitar la ambigüedad que permitirá una reutilización mejor / más fácil de nuestras simples API REST.
Puede usar solo GET y POST, pero luego está perdiendo algo de la precisión y la 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 administración de recursos, GET, PUT y DELETE probablemente cubran el 80% -90% de la funcionalidad requerida. Si se limita a GET y POST, se puede acceder al 40% -60% de su API utilizando el POST mal especificado.
Las aplicaciones web que utilizan GET y POST permiten a los usuarios crear, ver, modificar y eliminar sus datos, pero hacerlo en una capa sobre los comandos HTTP creados originalmente para estos fines. Una de las ideas detrás de REST es un retorno a la intención original del diseño de la Web, según el cual hay operaciones HTTP específicas para cada verbo CRUD.
También, el comando HEAD se puede usar para mejorar la experiencia del usuario para descargas de archivos (potencialmente grandes). Llamas a HEAD para averiguar qué tan grande será la respuesta y luego llamas a GET para recuperar el contenido.
Consulte el siguiente enlace para ver un ejemplo ilustrativo. También sugiere una forma de usar el método OPTIONS http, que aún no se ha discutido aquí.
Hay extensiones http como WebDAV que requieren funcionalidades adicionales.
La guerra de servidores web de los días anteriores probablemente lo haya causado.
En HTTP 1.0 escrito en 1996, solo había GET, HEAD y POST . Pero como puede ver en Apéndice D , los proveedores comenzaron a agregar sus cosas propias Por lo tanto, para mantener el HTTP compatible, se vieron obligados a hacer HTTP 1.1 en 1999 .
Sin embargo, HTTP / 1.0 no tiene suficientemente en cuenta los efectos de los 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í mismos " HTTP / 1.0 " ha requerido un cambio de versión del protocolo para dos aplicaciones de comunicación para determinar las verdaderas capacidades de cada uno.
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.
GET, PUT, DELETE y POST son restos de una época en la que los estudiantes de segundo año pensaban que una página web podría reducirse a unos pocos principios de hoighty toity.
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 podría tener formularios para ver o actualizar la información del cliente, que tal vez abarque varias tablas.
Usualmente uso $ _REQUEST [] en php, sin importarme realmente cómo llegó la información. Elegiría usar métodos GET o PUT basados ??en la eficiencia, no en los paradigmas subyacentes (múltiples).
