¿Qué código de estado debo establecer para UPDATE( PUT) y DELETE(por ejemplo, producto actualizado con éxito)?
¿Código de estado HTTP para actualizar y eliminar?
Respuestas:
Para una solicitud PUT : HTTP 200 o HTTP 204 deberían implicar "recurso actualizado con éxito".
Para una solicitud DELETE : HTTP 200 o HTTP 204 deberían implicar "recurso eliminado con éxito". HTTP 202 también se puede devolver, lo que implicaría que la instrucción fue aceptada por el servidor y que el "recurso se marcó para su eliminación".
Si se modifica un recurso existente, los códigos de respuesta 200 (OK) o 204 (Sin contenido)> DEBEN enviarse para indicar la finalización exitosa de la solicitud.
Una respuesta exitosa DEBE ser 200 (OK) si la respuesta incluye una entidad que describe el estado, 202 (Aceptada) si la acción aún no se ha promulgado, o 204 (Sin contenido) si la acción se ha promulgado pero la respuesta no incluye una entidad.
Fuente: W3.org: Definiciones de métodos HTTP / 1.1
HTTP 200 OK: respuesta estándar para solicitudes HTTP exitosas. La respuesta real dependerá del método de solicitud utilizado.
HTTP 204 Sin contenido: el servidor procesó con éxito la solicitud, pero no devuelve ningún contenido
40
Publicación muy útil! Sin embargo, me pregunto cuál debería ser el código de estado HTTP si la solicitud enviada por el cliente es válida (DELETE mySite / entity / 123 ) y la entidad a eliminar no existe.
—
Martin
@ Martin: En ese caso, el servicio debería devolver un HTTP 404. En sentido estricto, una solicitud DELETE o GET para un recurso que no existe no es una solicitud "válida", es decir. el cliente no debe volver a intentar esa solicitud porque nunca tendrá éxito ... El protocolo HTTP define 2 categorías de problemas: aquellos con un código de estado 4xx, donde el cliente debe modificar la solicitud antes de volver a intentarlo, y aquellos con un estado 5xx código, que indica que el servicio tuvo problemas y el cliente debería / podría volver a intentar la misma solicitud exacta sin cambiarla.
—
Daniel Vassallo
@JeffMartin Eso puede ser así desde el punto de vista del usuario, pero en lo que respecta al servidor, si el recurso no existe, el servidor debería devolver 404.
—
Randolpho
@Randolpho, Idempotence se trata de obtener el mismo resultado ya sea que invoques una operación una o varias veces. El cliente le pide que se asegure de que se elimine el recurso. ¿Cuál es el beneficio de devolver 404? ¿Por qué necesita saber de cualquier manera? Ahora la lógica del cliente tiene que manejar dos códigos de respuesta separados en lugar de uno.
—
Gili
@Gili: quizás la wiki explicará mejor: los métodos PUT y DELETE se definen como idempotentes ... tenga en cuenta que la idempotencia se refiere al estado del sistema después de que se haya completado la solicitud, por lo tanto, mientras la acción que realiza el servidor (por ejemplo, eliminar un registro ) o el código de respuesta que devuelve puede ser diferente en solicitudes posteriores, el estado del sistema será el mismo cada vez.
—
Randolpho
Respuesta corta: para PUT y DELETE, debe enviar 200 (OK) o 204 (Sin contenido).
Respuesta larga: aquí hay un diagrama de decisión completo (haga clic para ampliar).
El diagrama es asombroso. ¿Existe una versión de mayor resolución para imprimir?
—
KiKi
En el contexto de la POST de un recurso existente, otra discusión SO ( stackoverflow.com/questions/3825990/… ) sugiere enviar 409 Conflict o 302 Found en lugar de agregar el contenido.
—
koppor
Tengo curiosidad por saber si las respuestas 204 y 200 después de una eliminación deben revertirse, y si son correctas, ¿por qué? Eliminado? -> ¿La respuesta incluye una entidad? -> sí -> 204 Sin contenido; No -> 200 OK
—
Mt
La versión actualizada de la imagen está aquí: raw.github.com/for-GET/http-decision-diagram/master/httpdd.png
—
zaius
Falta PATCH.
—
doremi
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.
Esta respuesta se compone casi por completo de dos citas grandes, pero no hay atribución. ¿De dónde estás citando?
—
Quentin
¿Es 204 un estado apropiado para regresar para una solicitud PUT, si el estado no se cambia efectivamente? Por ejemplo, solicita desactivar un usuario pero el usuario ya está inactivo.
—
Ε Г И І И О
La solicitud PUT es idempotente, por lo que puede devolver un 204, porque el objeto ha cambiado en el sistema. PUT no es PATCH, por lo que no está seguro de qué campo desea cambiar. Puede enviar un 501 - 502, si su diseño necesita saber si el objeto era exactamente el mismo que el de la solicitud, pero ... Realmente no me gusta ... Prefiero 204 o, si quiere desactivar un usuario, sin cambiar más campos, tal vez pueda usar PATCH.
—
Alfonso Tienda
Añadiría HTTP 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.
—
vdboor
RFC 2616 describe qué códigos de estado usar .
Y no, no siempre es 200.
Además de 200 y 204, 205 (Restablecer contenido) podría ser una respuesta válida.
El servidor ha cumplido la solicitud y el agente de usuario DEBE restablecer la vista del documento que provocó el envío de la solicitud ... [por ejemplo] borrar el formulario en el que se proporciona la entrada.
Dado que la pregunta profundiza en si DELETE "debería" devolver 200 vs 204 , vale la pena considerar que algunas personas recomiendan devolver una entidad con enlaces, por lo que la preferencia es 200 .
"En lugar de devolver 204 (Sin contenido), la API debería ser útil y sugerir lugares a donde ir. En este ejemplo, creo que un enlace obvio para proporcionar es" 'somewhere.com/container/' (menos 'recurso') "- el contenedor del que el cliente acaba de eliminar un recurso. Quizás el cliente desee eliminar más recursos, por lo que sería un enlace útil ".
http://blog.ploeh.dk/2013/04/30/rest-lesson-learned-avoid-204-responses/
Si un cliente encuentra una respuesta 204, puede darse por vencido, ir al punto de entrada de la API o volver al recurso anterior que visitó. Ninguna de las opciones es particularmente buena.
Personalmente, no diría que 204 está mal (tampoco el autor; dice "molesto") porque el buen almacenamiento en caché del lado del cliente tiene muchos beneficios. Lo mejor es ser consistente de cualquier manera.
Aquí hay un código de estado, que debe conocer por su tipo de conocimiento.
Respuestas de información 1XX
- 100 Continuar
- 101 protocolos de conmutación
- 102 Procesamiento
- 103 primeros indicios
2XX éxito
- 200 OK
- 201 Creado
- 202 aceptado
- 203 Información no autorizada
- 204 Sin contenido
- 205 Restablecer contenido
- 206 Contenido parcial
- 207 multiestado
- 208 ya informado
- 226 IM usado
Redirección 3XX
- 300 opciones múltiples
- 301 movido permanentemente
- 302 encontrado
- 303 Ver otros
- 304 no modificado
- 305 Proxy de uso
- Proxy 306 Switch
- Redirección temporal 307
- Redirección permanente 308
Errores del cliente 4XX
- 400 Solicitud incorrecta
- 401 no autorizado
- 402 Pago requerido
- 403 prohibido
- 404 no encontrado
- Método 405 no permitido
- 406 no aceptable
- Se requiere autenticación de proxy 407
- 408 Tiempo de espera de solicitud
- 409 conflicto
- 410 ido
- 411 longitud requerida
- 412 Precondición fallida
- 413 Carga útil demasiado grande
- 414 URI demasiado largo
- 415 Tipo de medio no compatible
- Rango 416 no satisfactoria
- 417 Expectativa fallida
- 418 soy una tetera
- Falla del método 420
- 421 Solicitud mal dirigida
- 422 Entidad no procesable
- 423 bloqueado
- 424 Dependencia fallida
- 426 Actualización requerida
- 428 Condición previa requerida
- 429 Demasiadas solicitudes
- 431 Campos de encabezado de solicitud demasiado grandes
- 451 No disponible por razones legales
Errores del servidor 5XX
- 500 Error interno del servidor
- 501 no implementado
- 502 Bad Gateway
- 503 Servicio no disponible
- 504 tiempo de espera de puerta de enlace
- La versión 505 Http no es compatible
- 506 Varient También negociar
- 507 Almacenamiento insuficiente
- 508 lazo detectado
- 510 no extendido
- Se requiere autenticación de red 511
En junio de 2014, RFC7231 queda obsoleto RFC2616. Si está haciendo REST sobre HTTP, entonces RFC7231 describe exactamente qué comportamiento se espera de GET, PUT, POST y DELETE
Cuando se modifica un recurso, el código de respuesta debe ser 200 ("OK") . Si el estado del recurso cambia de una manera que cambia el URI al recurso (por ejemplo, se cambia el nombre de una cuenta de usuario), el código de respuesta es 301 ("Movido permanentemente") y el encabezado de ubicación debe proporcionar el nuevo URI.
Cuando se elimina un objeto, el código de respuesta debe ser 200 ("OK").
Siga el siguiente enlace para obtener más detalles: código de estado para descansar