Pregunta ¿Código de estado HTTP para actualizar y eliminar?


¿Qué código de estado debo configurar para UPDATE (PUT) y DELETE (por ejemplo, producto actualizado con éxito)?


992
2018-02-26 15:16


origen


Respuestas:


Para PONER solicitud: HTTP 200 o HTTP 204 debería implicar "recurso actualizado con éxito".

Para BORRAR solicitud: HTTP 200 o HTTP 204 debería 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 el "recurso fue marcado para su eliminación".

9.6 PUT

Si se modifica un recurso existente, se DEBERÁN enviar los códigos de respuesta 200 (OK) o 204 (Sin contenido)> para indicar que se completó con éxito la solicitud.

9.7 ELIMINAR

Una respuesta exitosa DEBERÍA ser 200 (OK) si la respuesta incluye una entidad que describe el estado, 202 (Aceptado) 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 HTTP exitoso   peticiones. La respuesta real   Depende del método de solicitud utilizado.

HTTP 204 Sin contenido: El servidor procesó correctamente la solicitud, pero no devuelve ningún contenido

Fuente: Lista de códigos de estado HTTP: 2xx Success


1543
2018-02-26 15:18



Respuesta corta: tanto para PUT como para DELETE, debe enviar 200 (OK) o 204 (Sin contenido).

Respuesta larga: aquí hay un diagrama de decisión completo (haga clic para ampliar).

HTTP 1.1 decision diagram

Fuente: https://github.com/for-GET/http-decision-diagram


717
2018-02-26 15:23



Aquí hay algunos consejos:

BORRAR

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

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

  • Si no hay nada que eliminar, use 204  o  404 (La operación DELETE es idempotente, eliminar un elemento ya eliminado es Operación exitosapara que puedas regresar 204, pero es cierto que idempotent no necesariamente implica la misma respuesta)

Otros errores

  • 400  Solicitud incorrecta (La sintaxis mal formada o una mala consulta es extraño pero posible).
  • 401  No autorizado Fallo de autentificacion
  • 403  Prohibido: Error de autorización o ID de aplicación no válida.
  • 405  No permitido. Por supuesto.
  • 409  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 las mismas razones que ELIMINAR arriba.
  • 202 si la operación no se ha comprometido aún.

El elemento al que se hace referencia no existe:

  • PUT puede ser 201 (si creaste el elemento porque ese es tu comportamiento)
  • 404 Si no quieres crear elementos a través de PUT.

  • 400  Solicitud incorrecta (Sintaxis mal formada o una mala consulta más común que en 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 mal formado) y valores de campo no válidos
  • Y 501, 502 en caso de errores

105
2017-09-24 12:14



RFC 2616 describe qué códigos de estado usar.

Y no, es no siempre 200.


13
2018-02-26 15:20



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] la eliminación del formulario en el que se proporciona la entrada.


7
2018-01-08 21:15



Dado que la pregunta profundiza en si BORRAR "debería" regresar 200 vs 204 Vale la pena considerar que algunas personas recomiendan devolver una entidad con enlaces por lo que la preferencia es para 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 a " 'somewhere.com/container/' (menos 'recurso') "- el contenedor desde el cual   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 a   el 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, sino "molesto") porque un buen almacenamiento en caché en el lado del cliente tiene muchos beneficios. Lo mejor es ser consistente de cualquier manera.


6
2018-05-29 02:02



En junio de 2014 RFC7231 obsoletos RFC2616. Si está haciendo REST a través de HTTP, entonces RFC7231 describe exactamente qué comportamiento se espera de GET, PUT, POST y DELETE


2
2017-11-22 15:52



Cuando se modifica un recurso, el código de respuesta debe ser 200 ("OK"). Si el estado del recurso cambia de una manera que cambie el URI al recurso (por ejemplo, se cambia el nombre de una cuenta de usuario), el 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 debería ser 200 ("OK")

Siga el enlace a continuación para obtener más detalles: código de estado para el descanso


0
2017-12-26 07:51