Advertencias en una API REST como errores no críticos

9

Tengo una API REST que para algunas empresas como DELETE, POST o PUT, tengo algunas reglas de validación que pueden devolver un error.

Ahora necesito un nuevo tipo de error, como un error no crítico, que debería fallar de manera normal, pero debería ir a la acción si hay un envío de banderas de "advertencias de supresión". Se le puede preguntar a dicho usuario: "¿Está seguro de que desea cambiar este estado? Todavía no ha terminado"

Pregunta : ¿existe una mejor práctica para este tipo de errores?

Preguntas secundarias :

  • ¿Hay alguna semántica HTTP para tal comportamiento que pueda usar?
  • ¿Todavía sigo la idea REST (para mí parece que sí) - Lo mantengo sin estado
rest api usuario237329
fuente
¿Cómo decides si mostrar tal advertencia a un usuario? Llama a un punto final de la API para verificar el estado de la aplicación y luego presenta al usuario dicho diálogo, bloqueando la IU hasta que el usuario responda. Entonces haces la llamada real. También debe modelar esto con su API REST: agregue un punto final para verificar si se guarda para realizar ciertas tareas. De esta forma, cualquier usuario de API puede realizar verificaciones "previas al vuelo" e incluso delegar la decisión a un usuario. Su enfoque de código de estado HTTP es como un rm /file"advierte" que el archivo es de solo lectura mientras lo borra de todos modos.
try-catch-finally
Esto sucede cuando el negocio se superpone con el código de estado del protocolo. De todos modos ¿Intentaste usar tu propio código de estado HTTP? Si Twitter puede, tú también. Digamos por ejemplo 6xx? De todos modos, hasta ahora lo sé, puede agregar mensajes en el cuerpo de respuesta incluso si es 4xx (qué rango sería apropiado en su caso).
Laiv
Finalmente utilicé 409 CONFLICTpara la respuesta de advertencia. De esta forma, se le indica al cliente que puede forzar la llamada con el mismo punto final y el mismo cuerpo con un parámetro adicional "force = 1"
user237329

Respuestas:

4

No hay códigos de resultado de advertencia en http, puede devolver un éxito (200) o un error (400, 500). Lo único que sé de eso podría ser análogo a lo que quieres es algo como el código 401 'no autorizado', que es una falla absoluta, pero hace que la mayoría de los clientes vuelvan a intentar conectarse automáticamente con credenciales.

Para una API REST, debe informar al servidor el estado de la solicitud y cómo manejar el resultado; no puede enviar un PUT y esperar un error si el cliente no está terminado, o éxito si lo ha hecho, el servidor necesita saber esto. información para devolver el código de resultado correcto.

Por lo tanto, puede enviar el indicador 'suprimir advertencias' con su solicitud, si no está configurado, el servidor devolverá un código de error 409 (o similar), y si está configurado, devolverá un código 200 en su lugar. No se le puede preguntar al usuario "¿Desea cambiar este estado?" Después de enviar el cambio de estado.

Puede hacer una solicitud al servidor para preguntar si el usuario puede cambiar el estado del curso y seguir con una solicitud adecuada después de eso.

gbjbaanb
fuente
No estoy diciendo que sea lo correcto, pero los códigos 3xx podrían verse como una especie de aviso o código de advertencia donde el cliente puede decidir proceder. Dicho esto, prefiero realizar una acción o no, y tal vez devuelva una respuesta con información adicional en el cuerpo devuelto o en los encabezados.
Archimedix
0

Si desea permitir que el usuario anule su manejo normal de errores, puede considerar devolver un estado de ÉXITO 200 con información adicional en los encabezados HTTP extendidos. Por ejemplo, podrías regresar

X-APP-STATUS: 422 Unprocessable entity
X-APP-SOURCE: Invalid ID 'fo0'

Esto le daría a su código del lado del cliente la información necesaria para advertir al usuario o tomar medidas correctivas por sí mismo.

TMN
fuente
2
Nunca me gustaron las respuestas que dicen "Fallé con éxito" :-)
gbjbaanb