http - verb - rest put example




PUT vs POST en REST (20)

El servidor de origen puede crear el recurso con ese URI.

Entonces usa POST y probablemente, pero no es necesario, PUT para la creación de recursos. No tienes que apoyar a ambos. Para mi POST es perfectamente suficiente. Así que es una decisión de diseño.

Como mencionó su cita, usted usa PUT para la creación de que no hay un recurso asignado a un IRI, y desea crear un recurso de todos modos. Por ejemplo, PUT /users/123/passwordgeneralmente reemplaza la contraseña anterior por una nueva, pero puede usarla para crear una contraseña si aún no existe (por ejemplo, usuarios recién registrados o restaurando usuarios prohibidos).

Según la especificación de HTTP / 1.1:

El método POST se utiliza para solicitar que el servidor de origen acepte la entidad incluida en la solicitud como un nuevo subordinado del recurso identificado por el Request-URI de Request-Line

En otras palabras, POST se utiliza para crear .

El método PUT solicita que la entidad adjunta se almacene bajo el Request-URI suministrado. Si la Request-URI refiere a un recurso ya existente, la entidad adjunta DEBERÍA considerarse como una versión modificada de la que reside en el servidor de origen. Si el Request-URI no apunta a un recurso existente, y ese URI es capaz de ser definido como un nuevo recurso por el agente del usuario solicitante, el servidor de origen puede crear el recurso con ese URI ".

Es decir, PUT se utiliza para crear o actualizar .

Entonces, ¿cuál debería usarse para crear un recurso? ¿O uno necesita apoyar a ambos?


Resumen:

Crear:

Se puede realizar tanto con PUT como con POST de la siguiente manera:

PONER

Crea el nuevo recurso con newResourceId como el identificador, bajo la URI / recursos, o colección .

PUT /resources/<newResourceId> HTTP/1.1 

ENVIAR

Crea un nuevo recurso bajo el URI / recursos, o colección . Normalmente el identificador es devuelto por el servidor.

POST /resources HTTP/1.1

Actualizar:

Solo se puede realizar con PUT de la siguiente manera:

PONER

Actualiza el recurso con existingResourceId como el identificador, bajo el URI / resources, o colección .

PUT /resources/<existingResourceId> HTTP/1.1

Explicación:

Cuando se trata de REST y URI como general, tiene genérico a la izquierda y específico a la derecha . Los genéricos se suelen llamar colecciones y los elementos más específicos se pueden llamar recurso . Tenga en cuenta que un recurso puede contener una colección .

Ejemplos:

<- genérico - específico ->

URI: website.com/users/john
website.com  - whole site
users        - collection of users
john         - item of the collection, or a resource

URI:website.com/users/john/posts/23
website.com  - whole site
users        - collection of users
john         - item of the collection, or a resource
posts        - collection of posts from john
23           - post from john with identifier 23, also a resource

Cuando usa POST, siempre se está refiriendo a una colección , por lo que siempre que diga:

POST /users HTTP/1.1

estás publicando un nuevo usuario en la colección de usuarios .

Si sigues e intentas algo como esto:

POST /users/john HTTP/1.1

funcionará, pero semánticamente está diciendo que desea agregar un recurso a la colección de john en la colección de usuarios .

Una vez que esté utilizando PUT, se está refiriendo a un recurso o elemento individual, posiblemente dentro de una colección . Así que cuando dices:

PUT /users/john HTTP/1.1

le está diciendo a la actualización del servidor, o cree, si no existe, el recurso john en la colección de usuarios .

Especulación:

Permítanme resaltar algunas partes importantes de la especificación:

ENVIAR

El método POST se utiliza para solicitar que el servidor de origen acepte la entidad incluida en la solicitud como un nuevo subordinado del recurso identificado por el URI de solicitud en la línea de solicitud

Por lo tanto, crea un nuevo recurso en una colección .

PONER

El método PUT solicita que la entidad adjunta se almacene bajo el URI de solicitud suministrado. Si la Solicitud-URI se refiere a un recurso ya existente , la entidad adjunta DEBERÍA considerarse como una versión modificada de la que reside en el servidor de origen. Si el Request-URI no apunta a un recurso existente , y ese URI es capaz de ser definido como un nuevo recurso por el agente del usuario solicitante, el servidor de origen puede crear el recurso con ese URI ".

Por lo tanto, crear o actualizar en función de la existencia del recurso .

Referencia:


POST significa "crear nuevo" como en "Aquí está la entrada para crear un usuario, créelo por mí".

PUT significa "insertar, reemplazar si ya existe" como en "Aquí están los datos para el usuario 5".

PUBLICAS en example.com/users porque aún no conoces la URL del usuario, quieres que el servidor la cree.

PONE en example.com/users/id ya que desea reemplazar / crear un usuario específico .

POSTing dos veces con los mismos datos significa crear dos usuarios idénticos con diferentes identificaciones. Poner dos veces con los mismos datos crea al usuario el primero y lo actualiza al mismo estado la segunda vez (sin cambios). Ya que terminas con el mismo estado después de un PUT, no importa cuántas veces lo realices, se dice que es "igualmente potente" cada vez: idempotente. Esto es útil para reintentar automáticamente las solicitudes. No más "¿está seguro de que desea volver a enviar" cuando presiona el botón Atrás en el navegador?

Un consejo general es utilizar POST cuando necesite que el servidor controle la generación de URL de sus recursos. Utilice PUT de lo contrario. Prefiero PUT sobre POST.


REST es un concepto de muy alto nivel. De hecho, ¡ni siquiera menciona HTTP en absoluto!

Si tiene alguna duda sobre cómo implementar REST en HTTP, siempre puede consultar la especificación Atom Publication Protocol (AtomPub) . AtomPub es un estándar para escribir servicios web RESTful con HTTP que fue desarrollado por muchas luminarias HTTP y REST, con algunas aportaciones de Roy Fielding, el inventor de REST y (co) inventor de HTTP.

De hecho, es posible que incluso puedas usar AtomPub directamente. Si bien salió de la comunidad de blogs, no se limita de ninguna manera a los blogs: es un protocolo genérico para interactuar RESTAMENTE con colecciones arbitrarias (anidadas) de recursos arbitrarios a través de HTTP. Si puede representar su aplicación como una colección anidada de recursos, entonces solo puede usar AtomPub y no preocuparse por usar PUT o POST, qué códigos de estado HTTP devolver y todos esos detalles.

Esto es lo que AtomPub tiene que decir sobre la creación de recursos (sección 9.2):

Para agregar miembros a una Colección, los clientes envían solicitudes POST al URI de la Colección.


Usted puede encontrar afirmaciones en la web que dicen

Tampoco está del todo bien.

Mejor es elegir entre PUT y POST en función de la idempotence de la acción.

PUT implica poner un recurso: reemplazar por completo lo que esté disponible en la URL dada por algo diferente. Por definición, un PUT es idempotente. Hazlo tantas veces como quieras, y el resultado es el mismo. x=5 es idempotente. Puede PONER un recurso, ya sea que exista previamente o no (por ejemplo, para Crear o Actualizar).

POST actualiza un recurso, agrega un recurso subsidiario o provoca un cambio. Un POST no es idempotente, de la manera en que x++ no es idempotente.

Por este argumento, PUT es para crear cuando conoce la URL de lo que creará. POST se puede utilizar para crear cuando conoce la URL de la "fábrica" ​​o el administrador de la categoría de cosas que desea crear.

asi que:

POST /expense-report

o:

PUT  /expense-report/10929

En general:

Se pueden usar tanto PUT como POST para crear.

Tienes que preguntar "¿a qué estás realizando la acción?" para distinguir lo que debes usar. Supongamos que estás diseñando una API para hacer preguntas. Si desea utilizar POST, debe hacerlo en una lista de preguntas. Si quieres usar PUT, entonces harías eso con una pregunta en particular.

Se pueden usar ambos, por lo que debería usar en mi diseño RESTful:

No es necesario que admita PUT y POST.

Lo que se usa se deja a ti. Pero recuerde usar el correcto en función del objeto al que haga referencia en la solicitud.

Algunas consideraciones:

  • ¿Nombra sus objetos URL que crea explícitamente o deja que el servidor decida? Si los nombras, entonces usa PUT. Si dejas que el servidor decida, usa POST.
  • PUT es idempotente, por lo que si PONE un objeto dos veces, no tendrá ningún efecto. Esta es una buena propiedad, así que usaría PUT cuando sea posible.
  • Puede actualizar o crear un recurso con PUT con la misma URL de objeto
  • Con POST puede recibir 2 solicitudes al mismo tiempo que realiza modificaciones a una URL, y pueden actualizar diferentes partes del objeto.

Un ejemplo:

Escribí lo siguiente como parte de otra respuesta en SO sobre esto :

ENVIAR:

Utilizado para modificar y actualizar un recurso.

POST /questions/<existing_question> HTTP/1.1
Host: www.example.com/

Tenga en cuenta que lo siguiente es un error:

POST /questions/<new_question> HTTP/1.1
Host: www.example.com/

Si la URL aún no se ha creado, no debe usar POST para crearla mientras especifica el nombre. Esto debería dar como resultado un error de 'recurso no encontrado' porque <new_question> aún no existe. <new_question> debe PONER el <new_question> en el servidor.

Sin embargo, podría hacer algo como esto para crear recursos utilizando POST:

POST /questions HTTP/1.1
Host: www.example.com/

Tenga en cuenta que en este caso no se especifica el nombre del recurso, se le devolverá la nueva ruta de la URL de los objetos.

PONER:

Se utiliza para crear un recurso, o sobrescribirlo. Mientras especificas los recursos, la nueva URL.

Para un nuevo recurso:

PUT /questions/<new_question> HTTP/1.1
Host: www.example.com/

Para sobrescribir un recurso existente:

PUT /questions/<existing_question> HTTP/1.1
Host: www.example.com/

Nueva respuesta (ahora que entiendo mejor a REST):

PUT es simplemente una declaración de qué contenido debe utilizar, a partir de ahora, el servicio para representar el recurso identificado por el cliente; POST es una declaración de qué contenido debe contener el servicio, a partir de ahora, (posiblemente duplicado) pero depende del servidor cómo identificar ese contenido.

PUT x(si xidentifica un resource ): "Reemplazar el contenido del recurso identificado xcon mi contenido".

PUT x(si xno identifica un recurso): "Cree un nuevo recurso que contenga mi contenido y utilícelo xpara identificarlo".

POST x: "Almacenar mi contenido y darme un identificador que pueda usar para identificar un recurso (antiguo o nuevo) que contenga dicho contenido (posiblemente mezclado con otro contenido). Dicho recurso debe ser idéntico o subordinado al que se xidentifica". " Y 'recurso s está subordinada a x ' recurso s" es típicamente, pero no necesariamente implementado por hacer y una subruta de x (por ejemplo, x = /fooy y = /foo/bar) y la modificación de la representación (s) de x recurso 's para reflejar la existencia de un nuevo recurso, por ejemplo, con un hipervínculo a yEl recurso y algunos metadatos. Solo lo último es realmente esencial para un buen diseño, ya que las URL son opacas en REST: se supone que debe utilizar hipermedia en lugar de la construcción de la URL del lado del cliente para atravesar el servicio de todos modos.

En REST, no existe un recurso que contenga "contenido". Me refiero como "contenido" a los datos que el servicio usa para hacer representaciones de manera consistente. Normalmente consta de algunas filas relacionadas en una base de datos o un archivo (por ejemplo, un archivo de imagen). Depende del servicio convertir el contenido del usuario en algo que el servicio pueda usar, por ejemplo, convertir una carga útil JSON en declaraciones SQL.

Respuesta original (podría ser más fácil de leer) :

PUT /something(si /somethingya existe): "Toma lo que tengas /somethingy reemplázalo con lo que te doy".

PUT /something(si /somethingaún no existe): "Toma lo que te doy y ponlo en /something".

POST /something: "Toma lo que te doy y colócalo en el lugar que quieras /something, siempre y cuando me des su URL cuando hayas terminado".


Respuesta corta:

Regla simple: use POST para crear, use PUT para actualizar.

Respuesta larga:

ENVIAR:

  • POST se utiliza para enviar datos al servidor.
  • Útil cuando la URL del recurso es desconocida

PONER:

  • PUT se utiliza para transferir el estado al servidor
  • Útil cuando se conoce la URL de un recurso

Respuesta más larga:

Para entenderlo, debemos preguntarnos por qué se requirió PUT, cuáles fueron los problemas que PUT estaba tratando de resolver que POST no pudo.

Desde el punto de vista de una arquitectura REST no hay nada que importe. Podríamos haber vivido sin PUT también. Pero desde el punto de vista del desarrollador de un cliente, su vida era mucho más sencilla.

Antes de PUT, los clientes no podían saber directamente la URL que generó el servidor o si todo lo que había generado o si los datos que se enviarán al servidor ya están actualizados o no. PUT alivió al desarrollador de todos estos dolores de cabeza. PUT es idempotente, PUT controla las condiciones de carrera y PUT permite al cliente elegir la URL.


Ambos se utilizan para la transmisión de datos entre el cliente y el servidor, pero existen diferencias sutiles entre ellos, que son:

Analogía:

  • PONER es decir, tomar y poner donde estaba.
  • Publicar como enviar correo en la oficina de correos.


Aquí hay una regla simple:

Se debe usar PUT en una URL para actualizar o crear el recurso que se puede ubicar en esa URL.

La POST a una URL debe usarse para actualizar o crear un recurso que se encuentre en otra URL ("subordinada"), o que no se pueda ubicar a través de HTTP.


En breve:

PUT es idempotente, donde el estado del recurso será el mismo si la misma operación se ejecuta una o varias veces.

POST no es idempotente, donde el estado del recurso puede ser diferente si la operación se ejecuta varias veces en comparación con la ejecución una sola vez.

Analogía con consulta de base de datos

PUEDE pensar que es similar a "ACTUALIZAR ESTUDIANTE SET dirección =" abc "donde id =" 123 ";

POSTE Puede pensar en algo como "INSERTAR EN EL ESTUDIANTE (nombre, dirección) VALORES (" abc "," xyzzz ");

La identificación del estudiante se genera automáticamente.

Con PUT, si la misma consulta se ejecuta varias veces o una vez, el estado de la tabla ESTUDIANTE sigue siendo el mismo.

En el caso de POST, si la misma consulta se ejecuta varias veces, se crean múltiples registros de Estudiantes en la base de datos y el estado de la base de datos cambia en cada ejecución de una consulta "INSERTAR".

NOTA: PUT necesita una ubicación de recursos (ya-recurso) en la que debe realizarse la actualización, mientras que POST no requiere eso. Por lo tanto, POST intuitivamente está destinado a la creación de un nuevo recurso, mientras que PUT es necesario para actualizar el recurso ya existente.

Algunos pueden llegar a que las actualizaciones se pueden realizar con POST. No hay una regla estricta sobre cuál usar para las actualizaciones o cuál usar para crear. Nuevamente, estas son convenciones, e intuitivamente me inclino por el razonamiento antes mencionado y lo sigo.


La mayoría de las veces, los usarás así:

  • Publicar un recurso en una colección
  • PONER un recurso identificado por la colección /: id

Por ejemplo:

  • POST / artículos
  • PUT / artículos / 1234

En ambos casos, el cuerpo de la solicitud contiene los datos para el recurso que se creará o actualizará. Debería ser obvio a partir de los nombres de ruta que POST no es idempotente (si lo llama 3 veces creará 3 objetos), pero PUT es idempotente (si lo llama 3 veces el resultado es el mismo). PUT se usa a menudo para la operación "upsert" (crear o actualizar), pero siempre puede devolver un error 404 si solo quiere usarlo para modificar.

Tenga en cuenta que POST "crea" un nuevo elemento en la colección y PUT "reemplaza" un elemento en una URL determinada, pero es una práctica muy común usar PUT para modificaciones parciales, es decir, usarlo solo para actualizar los recursos existentes y solo modifique los campos incluidos en el cuerpo (ignorando los otros campos). Esto es técnicamente incorrecto, si quiere ser purista de REST, PUT debería reemplazar todo el recurso y debería usar PATCH para la actualización parcial. Personalmente, no me importa mucho en la medida en que el comportamiento sea claro y coherente en todos los puntos finales de su API.

Recuerde, REST es un conjunto de convenciones y pautas para mantener su API simple. Si terminas con una solución complicada solo para marcar la casilla "RESTfull", estás derrotando el propósito;)


Se supone que la semántica es diferente, ya que "PUT", como "GET" se supone que es idempotente, lo que significa que puedes hacer la misma solicitud PUT exacta varias veces y el resultado será como si lo ejecutaras solo una vez.

Describiré las convenciones que creo que son las más utilizadas y útiles:

Cuando PONAS un recurso en una URL particular, lo que sucede es que debería guardarse en esa URL, o algo así.

Cuando PUBLICAS a un recurso en una URL particular, a menudo estás publicando una información relacionada a esa URL. Esto implica que el recurso en la URL ya existe.

Por ejemplo, cuando desea crear una nueva transmisión, puede PONERLO a alguna URL. Pero cuando desea POSTAR un mensaje a una transmisión existente, POST a su URL.

En cuanto a la modificación de las propiedades del flujo, puede hacerlo con PUT o POST. Básicamente, solo use "PUT" cuando la operación sea idempotente; de ​​lo contrario, use POST.

Sin embargo, tenga en cuenta que no todos los navegadores modernos admiten verbos HTTP distintos de GET o POST.


Si bien es probable que haya una forma agnóstica de describirlos, parece estar en conflicto con varias afirmaciones de las respuestas a los sitios web.

Seamos muy claros y directos aquí. Si usted es un desarrollador de .NET que trabaja con la API web, los datos son (de la documentación de la API de Microsoft), http://www.asp.net/web-api/overview/creating-web-apis/creating-a-web-api-that-supports-crud-operations :

1. PUT = UPDATE (/api/products/id)
2. MCSD Exams 2014 -  UPDATE = PUT, there are **NO** multiple answers for that question period.

Asegúrese de que "puede" usar "POST" para actualizar, pero simplemente siga las convenciones establecidas para usted con su marco dado. En mi caso, es .NET / Web API, por lo que PUT es para ACTUALIZAR que no hay debate.

Espero que esto ayude a cualquier desarrollador de Microsoft que lea todos los comentarios con enlaces a sitios web de Amazon y Sun / Java.


Voy a aterrizar con lo siguiente:

PUT se refiere a un recurso, identificado por el URI. En este caso, lo estás actualizando. Es la parte de los tres verbos que se refieren a los recursos: eliminar y obtener los otros dos.

POST es básicamente un mensaje de formato libre, cuyo significado se define como "fuera de banda". Si el mensaje puede interpretarse como agregar un recurso a un directorio, eso estaría bien, pero básicamente necesita entender el mensaje que está enviando (publicando) para saber qué ocurrirá con el recurso.

Debido a que PUT, GET y DELETE se refieren a un recurso, también son, por definición, idempotent.

POST puede realizar las otras tres funciones, pero luego la semántica de la solicitud se perderá en los intermediarios, como cachés y proxies. Esto también se aplica a proporcionar seguridad en el recurso, ya que el URI de una publicación no necesariamente indica el recurso al que se aplica (aunque puede).

Un PUT no necesita ser un creador; el servicio podría generar un error si el recurso aún no se ha creado, pero de lo contrario, actualícelo. O viceversa: puede crear el recurso, pero no permitir actualizaciones. Lo único que se requiere sobre PUT es que apunta a un recurso específico, y su carga útil es la representación de ese recurso. Un PUT exitoso significa (salvo interferencia) que un GET recuperaría el mismo recurso.

Edición: una cosa más: un PUT puede crear, pero si lo hace, entonces la ID debe ser una ID natural, también una dirección de correo electrónico. De esa manera, cuando PONAS dos veces, la segunda opción es una actualización de la primera. Esto lo hace idempotente .

Si se genera la ID (una nueva ID de empleado, por ejemplo), entonces el segundo PUT con la misma URL crearía un nuevo registro, que viola la regla idempotent. En este caso, el verbo sería POST y el mensaje (no el recurso) sería crear un recurso utilizando los valores definidos en este mensaje.


A riesgo de repetir lo que ya se ha dicho, parece importante recordar que PUT implica que el cliente controla lo que la URL va a terminar siendo, al crear un recurso. Por lo tanto, parte de la elección entre PUT y POST será sobre cuánto puede confiar en el cliente para que proporcione una URL correcta y normalizada que sea coherente con el esquema de URL.

Cuando no puede confiar completamente en que el cliente haga lo correcto, sería más apropiado usar POST para crear un nuevo elemento y luego enviar la URL al cliente en la respuesta.


La consideración más importante es la fiabilidad . Si un mensaje POST se pierde, el estado del sistema no está definido. La recuperación automática es imposible. Para los mensajes PUT, el estado es indefinido solo hasta el primer reintento exitoso.

Por ejemplo, puede que no sea una buena idea crear transacciones de tarjetas de crédito con POST.

Si tiene URI generados automáticamente en su recurso, aún puede usar PUT pasando un URI generado (que apunta a un recurso vacío) al cliente.

Algunas otras consideraciones:

  • POST invalida las copias en caché de todo el recurso que contiene (mejor consistencia)
  • Las respuestas PUT no se pueden almacenar en caché mientras que las POST son (Requerir ubicación de contenido y caducidad)
  • PUT es menos compatible con, por ejemplo, Java ME, navegadores más antiguos, cortafuegos

Los lectores nuevos en este tema se sorprenderán con la discusión interminable sobre lo que debe hacer y la relativa ausencia de lecciones de la experiencia. El hecho de que REST sea "preferido" sobre SOAP es, supongo, un aprendizaje de alto nivel a partir de la experiencia, pero ¿hay que progresar desde allí? Es 2016. La disertación de Roy fue en 2000. ¿Qué hemos desarrollado? ¿Fue divertido? ¿Fue fácil de integrar? ¿Apoyar? ¿Manejará el auge de los teléfonos inteligentes y las conexiones móviles inestables?

Según ME, las redes de la vida real no son confiables. Solicita tiempo de espera. Se restablecen las conexiones. Las redes se caen durante horas o días a la vez. Los trenes entran en túneles con usuarios móviles a bordo. Para cualquier solicitud dada (como se reconoce ocasionalmente en toda esta discusión) la solicitud puede caer en el agua en su camino, o la respuesta puede caer en el agua en su camino de regreso. En estas condiciones, emitir solicitudes PUT, POST y DELETE directamente contra recursos sustanciales siempre me ha parecido un poco brutal e ingenuo.

HTTP no hace nada para garantizar la finalización confiable de la solicitud-respuesta, y eso está bien porque este es el trabajo adecuado de las aplicaciones conscientes de la red. Al desarrollar una aplicación de este tipo, puede saltar a través de aros para usar PUT en lugar de POST, y luego más aros para dar un cierto tipo de error en el servidor si detecta solicitudes duplicadas. De vuelta en el cliente, entonces tienes que saltar a través de aros para interpretar estos errores, volver a obtener, revalidar y volver a publicar.

O puede hacer esto : considere sus solicitudes inseguras como recursos efímeros de un solo usuario (llamémosles acciones). Los clientes solicitan una nueva "acción" en un recurso sustantivo con un POST vacío para el recurso. POST será utilizado sólo para esto. Una vez que está seguro de poseer el URI de la acción recién acuñada, el cliente PONE la solicitud insegura al URI de acción, no al recurso objetivo . Resolver la acción y actualizar el recurso "real" es un trabajo adecuado de su API, y aquí se desacopla de la red no confiable.

El servidor hace el negocio, devuelve la respuesta y la almacena contra el URI de acción acordado . Si algo sale mal, el cliente repite la solicitud (¡comportamiento natural!), Y si el servidor ya la ha visto, repite la respuesta almacenada y no hace nada más .

Rápidamente notará la similitud con las promesas: creamos y devolvemos el marcador de posición para el resultado antes de hacer nada. También como una promesa, una acción puede tener éxito o fallar una vez, pero su resultado se puede recuperar repetidamente.

Lo mejor de todo es que damos a las aplicaciones de envío y recepción la oportunidad de vincular la acción identificada de manera única con la singularidad en sus respectivos entornos. Y podemos comenzar a exigir y aplicar el comportamiento responsable de los clientes: repita sus solicitudes todo lo que desee, pero no genere una nueva acción hasta que esté en posesión de un resultado definitivo del existente.

Como tal, numerosos problemas espinosos desaparecen. Las solicitudes de inserción repetidas no crearán duplicados, y no creamos el recurso real hasta que estemos en posesión de los datos. (Las columnas de la base de datos pueden permanecer sin nula). Las solicitudes de actualización repetidas no alcanzarán estados incompatibles y no sobrescribirán los cambios posteriores. Los clientes pueden (re) buscar y procesar sin problemas la confirmación original por cualquier motivo (el cliente se bloqueó, la respuesta se perdió, etc.).

Las solicitudes de eliminación sucesivas pueden ver y procesar la confirmación original, sin llegar a un error 404. Si las cosas tardan más de lo esperado, podemos responder provisionalmente y tenemos un lugar donde el cliente puede verificar el resultado definitivo. La mejor parte de este patrón es su propiedad de Kung-Fu (Panda). Tomamos una debilidad, la propensión a que los clientes repitan una solicitud cada vez que no entienden la respuesta y la convierten en una fortaleza :-)

Antes de decirme que esto no es REST, considere las numerosas formas en que se respetan los principios REST. Los clientes no construyen URL. La API permanece visible, aunque con un pequeño cambio en la semántica. Los verbos HTTP se usan apropiadamente. Si crees que este es un gran cambio para implementar, te puedo decir por experiencia que no lo es.

Si cree que tendrá grandes cantidades de datos para almacenar, hablemos de volúmenes: una confirmación de actualización típica es una fracción de un kilobyte. HTTP actualmente te da un minuto o dos para responder definitivamente. Incluso si solo almacena acciones durante una semana, los clientes tienen muchas posibilidades de ponerse al día. Si tiene volúmenes muy altos, es posible que desee un almacén de valores clave dedicado que cumpla con los requisitos de ácido, o una solución en memoria.


POST es como publicar una carta en un buzón o publicar un correo electrónico en una cola de correo electrónico. PUT es como cuando pones un objeto en un agujero de cubículo o un lugar en un estante (tiene una dirección conocida).

Con POST, estás publicando en la dirección de QUEUE o COLLECTION. Con PUT, estás poniendo a la dirección del ARTÍCULO.

PUT es idempotente. Puede enviar la solicitud 100 veces y no importará. POST no es idempotente. Si envía la solicitud 100 veces, recibirá 100 correos electrónicos o 100 cartas en su casilla postal.

Una regla general: si conoce el ID o el nombre del elemento, use PUT. Si desea que la parte receptora asigne el ID o el nombre del elemento, utilice POST.


Parece que siempre hay cierta confusión sobre cuándo usar HTTP POST en comparación con el método HTTP PUT para los servicios REST. La mayoría de los desarrolladores intentarán asociar las operaciones CRUD directamente a los métodos HTTP. Argumentaré que esto no es correcto y uno no puede simplemente asociar los conceptos de CRUD a los métodos HTTP. Es decir:

Create => HTTP PUT
Retrieve => HTTP GET
Update => HTTP POST
Delete => HTTP DELETE

Es cierto que R (etrieve) y D (elete) de las operaciones CRUD se pueden asignar directamente a los métodos HTTP GET y DELETE, respectivamente. Sin embargo, la confusión radica en las operaciones C (reate) y U (actualización). En algunos casos, se puede usar el PUT para crear, mientras que en otros casos se requerirá un POST. La ambigüedad radica en la definición de un método HTTP PUT frente a un método HTTP POST.

De acuerdo con las especificaciones HTTP 1.1, los métodos GET, HEAD, DELETE y PUT deben ser idempotentes, y el método POST no es idempotente. Es decir, una operación es idempotente si se puede realizar en un recurso una o varias veces y siempre devuelve el mismo estado de ese recurso. Mientras que una operación no idempotente puede devolver un estado modificado del recurso de una solicitud a otra. Por lo tanto, en una operación no idempotente, no hay garantía de que uno reciba el mismo estado de un recurso.

Según la definición de idempotente anterior, mi opinión sobre el uso del método HTTP PUT frente al método HTTP POST para los servicios REST es: Utilice el método HTTP PUT cuando:

The client includes all aspect of the resource including the unique identifier to uniquely identify the resource. Example: creating a new employee.
The client provides all the information for a resource to be able to modify that resource.This implies that the server side does not update any aspect of the resource (such as an update date).

En ambos casos, estas operaciones se pueden realizar varias veces con los mismos resultados. Es decir, el recurso no se modificará solicitando la operación más de una vez. Por lo tanto, una verdadera operación idempotente. Utilice el método HTTP POST cuando:

The server will provide some information concerning the newly created resource. For example, take a logging system. A new entry in the log will most likely have a numbering scheme which is determined on the server side. Upon creating a new log entry, the new sequence number will be determined by the server and not by the client.
On a modification of a resource, the server will provide such information as a resource state or an update date. Again in this case not all information was provided by the client and the resource will be changing from one modification request to the next. Hence a non idempotent operation.

Conclusión

No correlacione ni asigne directamente las operaciones CRUD a los métodos HTTP para los servicios REST. El uso de un método HTTP PUT en lugar de un método HTTP POST debe basarse en el aspecto idempotente de esa operación. Es decir, si la operación es idempotente, entonces use el método HTTP PUT. Si la operación no es idempotente, use el método HTTP POST.





put