PUT vs.POST en REPOSO

http rest post put


Según el HTTP/1.1 Spec:

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 usa para crear .

El método PUT solicita que la entidad adjunta se almacene bajo el Request-URI proporcionado . Si el Request-URI refiere a un recurso ya existente, la entidad adjunta DEBE 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 de usuario solicitante, el servidor de origen puede crear el recurso con ese URI ".

Es decir, PUT se usa para crear o reemplazar .

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




Answer 1 Brian R. Bondy


Overall:

Tanto el PUT como el POST pueden ser usados para crear.

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

Se pueden usar ambos geniales, entonces, ¿cuál debo usar en mi diseño RESTful?

No necesitas apoyar tanto el PUT como el POST.

Lo que se use queda a tu criterio.Pero recuerda usar el derecho dependiendo del objeto al que te refieras en la solicitud.

Algunas consideraciones:

  • ¿Nombra los objetos URL que crea explícitamente o deja que el servidor decida? Si los nombra,entonces use PUT.Si dejas que el servidor decida,entonces usa POST.
  • PUT es idempotente,así que si PUT un objeto dos veces,no tiene ningún efecto.Esta es una buena propiedad,así que usaría PUT cuando fuera posible.
  • Puedes actualizar o crear un recurso con PUT con el mismo objeto URL
  • Con el POST puedes tener 2 peticiones llegando al mismo tiempo haciendo modificaciones a una URL,y pueden actualizar diferentes partes del objeto.

Un ejemplo:

Escribí lo siguiente como parte de otra respuesta en SO con respecto a esto :

POST:

Se utiliza 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 recurso <new_question> en el servidor.

Sin embargo,podrías hacer algo como esto para crear un recurso usando POST:

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

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

PUT:

Se usa para crear un recurso,o para 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/

Además, y de manera un poco más concisa, RFC 7231 Sección 4.3.4 Estados PUT (énfasis agregado),

4.3.4. PONER

El método PUT solicita que el estado del recurso de destino se created o replaced con el estado definido por la representación incluida en la carga útil del mensaje de solicitud.




Answer 2 Cheeso


Puedes encontrar afirmaciones en la web que dicen

Ninguno de los dos está bien.


Mejor es elegir entre PUT y POST basado en la idempotencia de la acción.

PUT implica poner un recurso, reemplazar completamente 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 si ya existe o no (por ejemplo, para Crear o para Actualizar)!

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


Con este argumento,PUT es para crear cuando conoces la URL de la cosa que vas a crear.POST es para crear cuando sabes la URL de la "fábrica" o del administrador de la categoría de cosas que quieres crear.

so:

POST /expense-report

or:

PUT  /expense-report/10929



Answer 3 Nigel Thorne


  • POST a una URL crea un recurso hijo en una URL definida por el servidor .
  • PUT a una URL crea / reemplaza el recurso en su totalidad en la URL definida por el cliente .
  • PATCH a una URL actualiza parte del recurso en esa URL definida por el cliente.

La especificación relevante para PUT y POST es RFC 2616 §9.5ff.

POST crea un recurso hijo , por lo que POST a /items crea un recurso que vive debajo del recurso /items . P.ej. /items/1 . Enviar el mismo paquete postal dos veces creará dos recursos.

PUT es para crear o reemplazar un recurso en una URL conocida por el cliente .

Por lo tanto: PUT es solo un candidato para CREATE donde el cliente ya conoce la URL antes de que se cree el recurso. P.ej. /blogs/nigel/entry/when_to_use_post_vs_put ya que el título se usa como clave de recurso

PUT reemplaza el recurso en la URL conocida si ya existe, por lo que enviar la misma solicitud dos veces no tiene ningún efecto. En otras palabras, las llamadas a PUT son idempotentes .

El RFC se lee así:

La diferencia fundamental entre las solicitudes POST y PUT se refleja en el diferente significado de la solicitud-URI.La URI en una solicitud POST identifica el recurso que se encargará de la entidad adjunta.Ese recurso puede ser un proceso de aceptación de datos,una puerta de entrada a algún otro protocolo o una entidad separada que acepta anotaciones.Por el contrario,la URI en una solicitud PUT identifica la entidad incluida en la solicitud --el agente de usuario sabe qué URI está destinada y el servidor NO DEBE intentar aplicar la solicitud a algún otro recurso.Si el servidor desea que la solicitud se aplique a una URI diferente,

Nota: PUT se ha utilizado principalmente para actualizar recursos (reemplazándolos en su totalidad), pero recientemente se está moviendo hacia el uso de PATCH para actualizar los recursos existentes, ya que PUT especifica que reemplaza todo el recurso. RFC 5789.

Actualización 2018 : hay un caso que se puede hacer para evitar PUT. Consulte "DESCANSO sin PUT"

Con la técnica "REST sin PUT", la idea es que los consumidores se vean obligados a publicar nuevos recursos de solicitud 'no anunciados'. Como se discutió anteriormente, cambiar la dirección postal de un cliente es una POST a un nuevo recurso "ChangeOfAddress", no un PUT de un recurso "Cliente" con un valor de campo de dirección postal diferente.

tomado de REST API Design - Modelado de recursos por Prakash Subramaniam de Thoughtworks

Esto obliga a la API a evitar problemas de transición de estado con múltiples clientes que actualizan un solo recurso,y se ajusta más bien a la fuente de eventos y al CQRS.Cuando el trabajo se hace de forma asíncrona,la publicación de la transformación y la espera de su aplicación parece apropiada.




Answer 4 7hi4g0


Summary:

Create:

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

PUT

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

PUT /resources/<newResourceId> HTTP/1.1 

POST

Crea un nuevo recurso en el / resources URI, o colección . Por lo general, el servidor devuelve el identificador.

POST /resources HTTP/1.1

Update:

Puede solamente ser realizado con PUT de la siguiente manera:

PUT

Actualiza el recurso con existenteResourceId como el identificador, bajo el / URI de recursos, o colección .

PUT /resources/<existingResourceId> HTTP/1.1

Explanation:

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

Examples:

<- 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 refiere a una colección , así que cada vez que dice:

POST /users HTTP/1.1

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

Si sigues adelante 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 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 . Entonces cuando dices:

PUT /users/john HTTP/1.1

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

Spec:

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

POST

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 .

PUT

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

Por lo tanto, cree o actualice según la existencia del recurso .

Reference:




Answer 5 Alexander Torstling


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".

Usted POST AL a example.com/users ya que no conoce la URL del usuario, sin embargo, desea que el servidor para crearlo.

Usted PUT a example.com/users/id ya que desea reemplazar / crear un determinado usuario.

PUBLICAR dos veces con los mismos datos significa crear dos usuarios idénticos con diferentes identificadores. PONER dos veces con los mismos datos crea al usuario el primero y lo actualiza al mismo estado la segunda vez (sin cambios). Como 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 volver a intentar automáticamente las solicitudes. No más '¿estás seguro de que deseas reenviar' cuando presionas 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. Use PUT de lo contrario. Prefiere PUT sobre POST .