Avertissements dans une API REST en tant qu'erreurs non critiques

9

J'ai une API REST qui, pour certaines ententes comme DELETE, POST ou PUT, j'ai des règles de validation qui peuvent renvoyer une erreur.

Maintenant, j'ai besoin d'un nouveau type d'erreur comme une erreur non critique, qui devrait échouer de manière normale, mais devrait passer à l'action s'il y a un indicateur de "suppression des avertissements". Un tel utilisateur peut se demander: "Voulez-vous vraiment changer ce statut, vous n'avez pas encore terminé"

Question : existe-t-il une meilleure pratique pour ce type d'erreurs?

Questions secondaires :

Existe-t-il une sémantique HTTP pour un tel comportement que je peux utiliser?
puis-je toujours suivre l'idée REST (pour moi, ça a l'air que je fais) - je la garde apatride

rest api

— user237329
source

Comment décidez-vous d'afficher un tel avertissement à un utilisateur? Vous appelez un point de terminaison API pour vérifier l'état de l'application, puis présentez à l'utilisateur une telle boîte de dialogue, bloquant l'interface utilisateur jusqu'à ce que l'utilisateur réponde. Ensuite, vous effectuez l'appel réel. Vous devez également modéliser cela avec votre API REST: ajoutez un point de terminaison pour vérifier s'il est enregistré pour effectuer certaines tâches. De cette façon, tout utilisateur de l'API peut effectuer des vérifications «avant le vol» et même déléguer la décision à un utilisateur. Votre approche du code de statut HTTP est comme rm /filecelle qui "avertit" que le fichier est en lecture seule tout en le supprimant de toute façon.

— try-catch-finally

Cela se produit lorsque l'entreprise chevauche le code d'état du protocole. Bref. Avez-vous essayé d'utiliser votre propre code de statut HTTP? Si Twitter le peut, vous aussi. Disons par exemple 6xx? Quoi qu'il en soit, jusqu'à présent, je sais, vous pouvez ajouter des messages dans le corps de la réponse même si c'est 4xx (quelle plage serait appropriée dans votre cas).

— Laiv

Enfin, j'ai utilisé 409 CONFLICTpour la réponse d'avertissement. De cette façon, le client est informé qu'il peut forcer l'appel avec le même point de terminaison et le même corps avec un paramètre exttra "force = 1"

— user237329

4

Il n'y a pas de code de résultat d'avertissement dans http, vous retournez soit un succès (200) soit une erreur (400, 500). La seule chose que je sache qui pourrait être analogue à ce que vous voulez est quelque chose comme le code 401 `` non autorisé '' - ce qui est un échec pur et simple, mais oblige la plupart des clients à réessayer automatiquement la connexion avec les informations d'identification.

Pour une API REST, vous devez indiquer au serveur l'état de la demande et comment gérer le résultat - vous ne pouvez pas envoyer de PUT et vous attendre à une erreur si le client n'est pas terminé, ou à un succès si c'est le cas - le serveur doit le savoir informations afin de renvoyer le bon code de résultat.

Vous pouvez donc envoyer l'indicateur «supprimer les avertissements» avec votre demande, s'il n'est pas défini, le serveur renverra un code d'erreur 409 (ou similaire), et s'il est défini, renvoie un code 200 à la place. On ne peut pas demander à l'utilisateur «voulez-vous changer ce statut» après l'envoi du changement de statut.

Vous pouvez faire une demande au serveur pour demander si l'utilisateur peut changer de statut bien sûr et suivre avec une demande appropriée après cela.

— gbjbaanb
source

Je ne dis en aucun cas que c'est la bonne chose à faire, mais les codes 3xx pourraient être considérés comme une sorte de code de notification ou d'avertissement où le client peut décider de procéder. Cela dit, je préfère effectuer une action ou non, et peut-être que je renvoie une réponse avec des informations supplémentaires dans le corps renvoyé ou dans les en-têtes.

— Archimedix

0

Si vous souhaitez autoriser l'utilisateur à remplacer votre gestion d'erreur normale, vous pouvez envisager de renvoyer un état 200 SUCCESS avec des informations supplémentaires dans les en-têtes HTTP étendus. Par exemple, vous pouvez retourner

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

Cela donnerait à votre code côté client les informations nécessaires pour avertir l'utilisateur ou prendre des mesures correctives de son propre chef.

— TMN
source

2

Je n'ai jamais aimé les réponses qui disent "J'ai échoué avec succès" :-)

— gbjbaanb