¿Qué llamadas REST PUT / POST / DELETE deben devolverse por convención?

153

  1. De acuerdo con la "ideología REST", ¿qué debe estar en el cuerpo de respuesta para una solicitud PUT / POST / DELETE?

  2. ¿Qué pasa con los códigos de retorno? Es HTTP_OKsuficiente?

  3. ¿Cuál es la razón de tales convenciones, si hay alguna?

He encontrado una buena publicación que describe las diferencias POST / PUT: POST vs PUT Pero todavía no responde mi pregunta.

rest http post http-delete tuxSlayer
fuente

Respuestas:

130

Perdone la ligereza, pero si está haciendo REST sobre HTTP, RFC7231 describe exactamente qué comportamiento se espera de GET, PUT, POST y DELETE.

Actualización (3 de julio de 2014):
la especificación HTTP intencionalmente no define lo que se devuelve desde POST o DELETE. La especificación solo define lo que debe definirse. El resto queda a cargo del implementador para que elija.

Darrel Miller
fuente
9
@tuxslayer Me alegro de que no pensaras que solo estaba tratando de ser sarcástico. Mucha gente parece pensar que REST agrega requisitos de adición además de los métodos HTTP. Sin embargo, este no es el caso. Existen restricciones adicionales, pero en realidad no afectan el comportamiento de los métodos HTTP. RFC2616 es definitivamente la guía a seguir.
Darrel Miller el
44
Agradezco el enlace. :) Me hizo parar y pensar en la herramienta que estoy usando. Después de leer su publicación y el RFC, me encontré refiriéndome al RFC el resto de la noche. Me ayudó a pensar en el proceso como un proceso HTTP primero, y un proceso de descanso en segundo lugar. Muy apreciado.
Perry Tew
44
@PerryTew Ahora puede ir aquí tools.ietf.org/wg/httpbis y ver la versión revisada actualmente de la especificación HTTP. ¡Disfrutar!
Darrel Miller
12
Tal vez solo necesito dormir más, pero parece que no puedo encontrar la información exacta que el OP solicitó dentro del RFC. ¿Cuál debería ser el cuerpo para una respuesta POST o DELETE?
Cam Jackson
9
Bueno, eso es casi tan claro como el barro. Quizás alguna información más en la respuesta sería útil. Especialmente, cuando ese enlace está muerto.
Doug Molineux
25

En general, las convenciones son "piensa que solo estás entregando páginas web".

Para un PUT, devolvería la misma vista que obtendría si hiciera un GET inmediatamente después; eso daría como resultado un 200 (bueno, suponiendo que la representación tenga éxito, por supuesto). Para una POST, haría una redirección al recurso creado (suponiendo que esté haciendo una operación de creación; si no, simplemente devuelva los resultados); el código para una creación exitosa es 201, que es realmente el único código HTTP para una redirección que no está en el rango de 300.

Nunca me gustó lo que debería devolver DELETE (mi código actualmente produce un HTTP 204 y un cuerpo vacío en este caso).

Compañeros de Donal
fuente
1
Hacer que la PUTsolicitud devuelva la página siguiente parece una mala práctica, ya que actualizar la página resultante hará que la solicitud se ejecute nuevamente. En cambio, para mí, tiene sentido hacer una redirección, suponiendo que se trata de solicitudes sincrónicas.
lobati
1
@lobati Creo que es importante tener en cuenta que el envío de múltiples solicitudes PUT idénticas debería tener exactamente el mismo resultado que el envío de solo una de las mismas solicitudes PUT. ¿Quizás el problema que planteas ahora es menos importante dado lo anterior?
Iain
3
@ No estoy realmente. El problema es que si algo más actualiza el registro más tarde, no querrá que envíe otra PUTsolicitud que provoque la reversión de los datos. Por ejemplo, si dos personas hacen referencia a la misma página, una realiza una actualización, la otra hace una actualización, si la primera persona se actualiza para ver el resultado, terminaría haciendo que las cosas se reviertan antes de que la segunda persona realice sus cambios
lobati
"Pensar como sitio web" es perfecto, por lo tanto, una eliminación puede responder con algunas próximas acciones probables, que dependen de la "historia" sobre por qué eliminaría un recurso. Esto podría ser al menos un enlace para llevar al agente de regreso a un punto de inicio lógico de acciones, o incluso una redirección a un recurso de estado que muestre el impacto de la eliminación (total del pedido) y contenga más enlaces.
Luke Puplett
3

La creación de un recurso generalmente se asigna a POST, y eso debería devolver la ubicación del nuevo recurso; por ejemplo, en un andamio Rails, un CREATE redirigirá al SHOW para el recurso recién creado. El mismo enfoque podría tener sentido para la actualización (PUT), pero eso es menos convencional; una actualización solo necesita indicar éxito. Una eliminación probablemente solo necesite indicar éxito también; si desea redirigir, devolver la LISTA de recursos probablemente tenga más sentido.

El éxito puede ser indicado por HTTP_OK, sí.

La única regla estricta en lo que he dicho anteriormente es que un CREATE debería devolver la ubicación del nuevo recurso. Eso me parece una obviedad; tiene mucho sentido que el cliente deba poder acceder al nuevo elemento.

Jacob Mattison
fuente
2
De hecho, has mezclado PUT y POST. POST se usa para crear, PUT se usa para actualizar (y crear). También vale la pena señalar que PUT debe ser idempotente mientras que POST no lo es.
Stevie
Un comando idempotente debería funcionar correctamente sin importar cuántas veces lo ejecute. Por lo tanto, debe poder hacer el mismo PUT varias veces para aplicar la misma "actualización" sin ningún efecto secundario negativo.
Jacob Mattison el
1

Por el RFC7231 no importa y puede estar vacío

Cómo implementamos la solución basada en el estándar json api en el proyecto:

post / put: genera atributos de objeto como en get (el filtro de campo / relaciones aplica lo mismo)

eliminar: los datos solo contienen nulos (por su representación del objeto perdido)

estado para eliminación estándar: 200

Marius Gri
fuente
0

Me gusta Alfonso Tienda responde del código de estado HTTP para actualizar y eliminar.

Aquí hay algunos consejos:

ELIMINAR

  • 200 (si desea enviar algunos datos adicionales en la Respuesta) o 204 (recomendado).

  • 202 La operación eliminada aún no se ha confirmado.

  • Si no hay nada que eliminar, use 204 o 404 (la operación ELIMINAR es idempotente, eliminar un elemento ya eliminado es una operación exitosa , por lo que puede devolver 204 , pero es cierto que idempotente no necesariamente implica la misma respuesta)

Otros errores:

  • 400 Solicitud incorrecta (la sintaxis con formato incorrecto o una consulta incorrecta es extraña pero posible).
  • 401 Error de autenticación no autorizada
  • 403 Prohibido : error de autorización o ID de aplicación no válida.
  • 405 no permitido . Por supuesto.
  • 409 El conflicto de recursos puede ser posible en sistemas complejos.
  • Y 501 , 502 en caso de errores.

PONER

Si está actualizando un elemento de una colección

  • 200/204 con los mismos motivos que ELIMINAR arriba.
  • 202 si la operación aún no se ha comprometido.

El elemento referenciado no existe:

  • PUT puede ser 201 (si creó el elemento porque ese es su comportamiento)

  • 404 Si no desea crear elementos mediante PUT.

  • 400 Solicitud incorrecta (la sintaxis con formato incorrecto o una consulta incorrecta es más común que en el caso de DELETE).

  • 401 no autorizado

  • 403 Prohibido : error de autenticación o ID de aplicación no válida.

  • 405 no permitido . Por supuesto.

  • 409 Conflicto de recursos puede ser posible en sistemas complejos, como en DELETE.

  • 422 Entidad no procesable Ayuda a distinguir entre una "Solicitud incorrecta" (por ejemplo, XML / JSON con formato incorrecto) y valores de campo no válidos

  • Y 501 , 502 en caso de errores.

Ryabchenko Alexander
fuente