Según la "ideología REST", ¿qué debería estar en el cuerpo de respuesta para las solicitudes PUT/POST/DELETE?¿Qué llamadas REST PUT/POST/DELETE deben devolver por convención?
¿Qué hay de los códigos de retorno? ¿Es suficiente HTTP_OK?
¿Cuál es el motivo de tales convenciones, si las hay?
que he encontrado un buen puesto describir las diferencias/PUT de la publicación: POST vs PUT Pero todavía no responde a mi pregunta.
Perdone la ligereza, pero si está haciendo REST a través de HTTP, entonces RFC7231 describe exactamente qué comportamiento se espera de GET, PUT, POST y DELETE.
En general, las convenciones son "pensar como si solo estuvieras 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 el renderizado tenga éxito, por supuesto). Para un POST, haría un redireccionamiento al recurso creado (suponiendo que estés haciendo una operación de creación; si no, solo devuelve los resultados); el código para una creación exitosa es un 201, que es realmente el único código HTTP para una redirección que no está en el rango 300.
Nunca me ha gustado lo que DELETE debería devolver (mi código actualmente produce un HTTP 204 y un cuerpo vacío en este caso).
Tener la solicitud 'PUT' devolviendo la página siguiente parece una mala práctica, ya que refrescar en 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
@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 enviar solo una de las mismas solicitudes PUT. Tal vez el problema que plantea ahora es menos importante dado lo anterior? – Iain
@Iain no realmente. El problema es que, si algo más actualiza el registro más tarde, no le gustaría que le enviara otra solicitud 'PUT' que causa la reversión de los datos. Por ejemplo, si dos personas hacen referencia a la misma página, una hace una actualización y luego 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 sus cambios – lobati
La creación de un recurso generalmente se correlaciona con POST, y eso debería devolver la ubicación del nuevo recurso; por ejemplo, en un andamio de Rails, un CREATE redirigirá al SHOW para el recurso recién creado. El mismo enfoque puede tener sentido para la actualización (PUT), pero eso es menos convencional; una actualización solo necesita indicar el éxito. Una eliminación probablemente solo necesite indicar el éxito también; si desea redirigir, devolver la LISTA de recursos probablemente tenga más sentido.
El éxito se puede indicar mediante HTTP_OK, sí.
La única regla difícil en lo que he dicho anteriormente es que un CREATE debe devolver la ubicación del nuevo recurso. Eso parece una obviedad para mí; tiene perfecto sentido que el cliente necesite poder acceder al nuevo elemento.
Has confundido PUT y POST. POST se usa para crear, PUT se usa para actualizar (y crear). También vale la pena observar que PUT debe ser idempotente, mientras que POST no lo es. – Stevie
Tienes razón; Los cambié –
Sí, he echado de menos este hecho. ¡Gracias!Esto parece mucho más lógico que "inventar" un nuevo significado para cada "método" http y seguramente más lógico que el mapeo de las operaciones SQL. – tuxSlayer
@tuxslayer Me alegra que no pensaras que solo estaba tratando de ser sarcástica. Muchas personas parecen pensar que REST agrega requisitos adicionales sobre 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. –
Aprecio 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. –