verbos peticion metodos metodo entre diferencia rest

rest - peticion - ¿Por qué necesitamos algo más que HTTP GET, PUT, POST?



metodos http rest (14)

¿Por qué necesitamos más de 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 de caché intermedios pueden tener una mejor oportunidad de hacer lo correcto.

Piense 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é.

¿Cuál es el beneficio práctico de usar 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é no deberíamos usar GET, PUT y POST (y soltar HEAD, DELETE)?

La guerra del servidor web de los primeros días probablemente lo causó.

En HTTP 1.0 escrito en 1996, solo había GET, HEAD y POST . Pero como puede ver en el Apéndice D , los vendedores comenzaron a agregar sus propias cosas. Por lo tanto, para mantener 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 los hosts virtuales. Además, la proliferación de aplicaciones implementadas de manera incompleta llamándose a sí mismas "HTTP / 1.0" ha necesitado un cambio de versión de protocolo para que dos aplicaciones en comunicación determinen las verdaderas capacidades 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 para garantizar la implementación confiable de sus características.

Para limitar la ambigüedad que permitirá una mejor / más fácil reutilización de nuestras apis REST simples.

Podrías usar solo GET y POST pero luego estás perdiendo algo 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, GET, PUT y DELETE probablemente cubran entre el 80% y el 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.

El método [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 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 nuevos objetos. El URI no tiene clave; acepta un cuerpo de mensaje que define el objeto. Insertar SQL. [ Editar Aunque no existe una razón técnica para que POST no tenga ninguna clave, los usuarios de REST sugieren firmemente que para que POST tenga un significado distinto como CREAR, no debería tener una clave.]

GET recupera 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.

DELETE borra 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ías insistir en alguna 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.

Podría hacer un caso que UPDATE debería insertar 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.

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 se podía reducir a unos pocos principios de la vejez.

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.

Usualmente uso $ _REQUEST [] en php, sin importarme realmente 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).

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.

Vea el siguiente enlace para un ejemplo ilustrativo. También sugiere una forma de utilizar el método OPTIONS http, que aún no se ha discutido aquí.

POST no tiene garantías de seguridad o idempotencia . 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 utiliza para establecer el estado de un recurso en un URI determinado. Cuando envía una solicitud POST a un recurso en un URI particular, ese recurso no debe ser reemplazado por el contenido. A lo sumo, debe agregarse 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 nuevo mensaje en un foro de discusión cada vez).

DELETE se utiliza para garantizar que un recurso en un URI determinado se elimine del servidor. POST normalmente no se debe usar para eliminar, excepto en el caso de enviar 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 usa si lo único que te interesa son los encabezados de una solicitud GET y no quieres perder ancho de banda en el contenido real. Esto es bueno tener

Nadie publicó el tipo de respuesta que estaba buscando, así que intentaré resumir los puntos yo mismo.

El capítulo 8 de la sección "Sobrecarga de POST" del capítulo 8 de "Servicios RESTful" 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, 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 algunas palabras más:

GET = seguro + idempotente

PUT = idempotent

DELETE = idempotent

POST = ni seguro ni idempotente

''Idempotente'' 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 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.

Este es realmente un concepto bastante importante porque proporciona una forma estándar / consistente de interpretar transacciones HTTP; esto es particularmente útil en un contexto de seguridad.

HEAD es realmente útil para determinar en qué reloj de un servidor determinado está configurado (con una precisión de 1 segundo o el tiempo de ida y vuelta de la red, el que sea mayor). También es excelente para obtener cotizaciones de Futurama de 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 solicitud HEAD. Para obtener la fecha y hora actual de un servidor determinado, solo hazlo

curl -I $server | grep ^Date