Avisos em uma API REST como erros não críticos

9

Eu tenho uma API REST que, para algumas pessoas como DELETE, POST ou PUT, tenho algumas regras de validação que podem retornar um erro.

Agora, preciso de um novo tipo de erro, como um erro não crítico, que deve falhar normalmente, mas deve executar a ação se houver um sinalizador de "supress warnings" enviado. Pode-se perguntar a um usuário: "Tem certeza de que deseja alterar esse status? Ainda não terminou"

Pergunta : existe uma prática recomendada para esse tipo de erro?

Questões secundárias :

Existe alguma semântica HTTP para esse comportamento que eu possa usar?
eu ainda sigo a ideia REST (para mim, parece que eu faço) - eu a mantenho apátrida

rest api

— user237329
fonte

Como você decide se deve mostrar esse aviso a um usuário? Você chama um ponto de extremidade da API para verificar o status do aplicativo e, em seguida, apresenta ao usuário uma caixa de diálogo, bloqueando a interface do usuário até que o usuário responda. Então você faz a ligação real. Você também deve modelar isso com a API REST: adicione um terminal para verificar se é salvo para executar determinadas tarefas. Dessa forma, qualquer usuário da API é capaz de fazer verificações "pré-vôo" e até delegar a decisão a um usuário. Sua abordagem do código de status HTTP é como uma rm /file"advertência" de que o arquivo é somente leitura enquanto o exclui.

— try-catch-finalmente

Isso acontece quando os negócios se sobrepõem ao código de status do protocolo. Enfim. Você tentou usar seu próprio 'código de status HTTP? Se o Twitter puder, você também. Vamos dizer, por exemplo, 6xx? De qualquer forma, até agora eu sei, você pode adicionar mensagens ao corpo da resposta, mesmo que seja 4xx (qual intervalo seria apropriado no seu caso).

— Laiv 13/05/19

Finalmente eu usei 409 CONFLICTpara resposta de aviso. Dessa forma, o cliente é instruído a poder forçar a chamada com o mesmo ponto final e corpo com parâmetros exttra "force = 1"

— user237329

4

Não há códigos de resultado de aviso em http; você retorna um sucesso (200) ou um erro (400, 500). A única coisa que sei que pode ser análoga ao que você deseja é algo como o código 401 'não autorizado' - que é uma falha total, mas faz com que a maioria dos clientes tente novamente automaticamente a conexão com credenciais.

Para uma API REST, você precisa informar ao servidor o status da solicitação e como lidar com o resultado - não é possível enviar uma PUT e esperar um erro se o cliente não terminar, ou êxito, se houver - o servidor precisa saber disso informações para enviar de volta o código de resultado correto.

Portanto, você pode enviar o sinalizador 'suprimir avisos' com sua solicitação, se não estiver definido, o servidor retornará um código de erro 409 (ou similar) e, se definido, retornará um código 200. Não é possível perguntar ao usuário 'você deseja alterar este status' após o envio da alteração de status.

Você pode fazer uma solicitação ao servidor para perguntar se o usuário pode alterar o status naturalmente e seguir com uma solicitação apropriada depois disso.

— gbjbaanb
fonte

Não estou dizendo que é a coisa certa a fazer, mas os códigos 3xx podem ser vistos como algum tipo de código de aviso ou aviso em que o cliente pode decidir continuar. Dito isto, prefiro executar uma ação ou não, e talvez eu retorne uma resposta com informações adicionais no corpo retornado ou nos cabeçalhos.

— Archimedix #

0

Se você deseja permitir que o usuário substitua seu tratamento normal de erros, considere retornar um status 200 SUCCESS com informações adicionais em cabeçalhos HTTP estendidos. Por exemplo, você pode retornar

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

Isso daria ao código do lado do cliente as informações necessárias para avisar o usuário ou executar ações corretivas por conta própria.

— TMN
fonte

2

Eu nunca gostei de respostas que dizem "eu falhei com sucesso" :-)

— gbjbaanb