De acuerdo con la "ideología REST", ¿qué debe estar en el cuerpo de respuesta para una solicitud PUT / POST / DELETE?
¿Qué pasa con los códigos de retorno? Es HTTP_OKsuficiente?
¿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.
Respuestas:
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.
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).
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.
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
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.
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
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.