SOAP fautes ou objet de résultats?

Question

J'avais une discussion à ce sujet avec un collègue et nous n'avons pas pu parvenir à un accord, alors je voulais avoir votre avis. J'ai mes propres opinions à ce sujet, mais je ne vous gâcherai pas.

Quand dois-je renvoyer un erreur SOAP et quand dois-je renvoyer un objet de résultat contenant des informations d'erreur? Supposons qu'il s'agit d'un service Web générique pouvant être utilisé par divers systèmes (.NET, Java, peu importe). L'objet résultat aurait un indicateur isError, un errorType (similaire au type d'exception spécifique) et un message.

Quelques points à considérer:

1. Une erreur de validation des données est-elle un défaut?
2. Doit-il y avoir une combinaison de défauts (pour des cas très exceptionnels) et de l'objet résultats (pour des erreurs "attendues")?
3. Comment regrouperiez-vous SOAP défauts (critique [référence nulle] vs validation [Code postal incorrect])?
4. Échec rapide vs devoir se rappeler de vérifier l'erreur
5. Meilleures pratiques, modèles, normes, etc.

Les liens vers les articles sont valides. Même s'il semble que je veux votre avis, veuillez vous en tenir aux faits (x vaut mieux à cause de y et z ...)

Answer 1

La plupart des clients SOAP convertissent les erreurs en une exception d'exécution (si c'est quelque chose que le langage client prend en charge). Dans cet esprit, je pense que vous pouvez reformuler la question comme "Quand dois-je lancer une exception au lieu de renvoyer une valeur d'erreur "? Je suis sûr que vous pouvez trouver beaucoup d'opinions sur cette conception d'API en général et sur ce sujet en particulier.

Cela dit, le retour d'une erreur n'est généralement pas utile au client:

1. Le client doit énumérer et gérer manuellement vos codes d'erreur par rapport à permettre au code de stub de générer et de lever une exception du type approprié. L'utilisation de codes d'erreur empêche le client d'utiliser des techniques orientées objet telles que la gestion des exceptions par superclasse.

2. Si vous ne faites pas partie de vos codes d'erreur du WSDL; le client n'aura aucune documentation sur ce qu'ils sont ou quand ils se produisent. Les fautes typées font partie du WSDL et donc (dans une certaine mesure limitée) l'auto-documentation.

3. Les messages d'erreur peuvent contenir un contexte spécifique à l'erreur que le client peut utiliser pour le rapport d'erreurs et la récupération. Par exemple, lancer une erreur de validation d'entrée contenant l'élément d'entrée non valide réel et une raison. Si vous renvoyez un résultat avec un code d'erreur et une chaîne opaque, le client n'a d'autre choix que de transmettre votre message d'erreur à l'utilisateur, ce qui rompt l'internationalisation, la cohérence de l'interface utilisateur, etc.

Pour répondre à vos questions spécifiques:

1. Une erreur de validation est un défaut. Imaginez si vous appelez le service Web à partir d'un client AJAX avec une capacité de gestion des erreurs limitée; vous voulez que le service renvoie un code HTTP 5xx, pas un code de réussite 400 avec une réponse inattendue.

2. Non. Les API doivent fournir des interfaces de rapport d'erreurs cohérentes. La conception WSDL est une conception API. Forcer le client à implémenter deux gestionnaires d'erreurs distincts ne facilite pas la vie du client.

3. La conception des défauts doit refléter votre modèle de demande/réponse et afficher les informations appropriées à l'abstraction du service. Ne concevez pas de défaut NullReference; concevoir un XYZServiceRuntimeFault. Si les clients fournissent fréquemment des demandes non valides, concevez un InvalidRequestFault, avec des sous-classes appropriées afin que les clients puissent rapidement trouver où se trouvent les données non valides.

Answer 2

Un objet résultats ne doit contenir que des résultats. Si votre objet de résultat fournit une liste d'erreurs qui se sont produites sur un autre système, c'est un exemple de quand vous pouvez avoir et l'indicateur "isError"; sinon vous ne pouvez pas car un résultat est valide ou non.

Vous devez toujours utiliser un SOAPFault lorsqu'une erreur se produit. La validation est une erreur, et c'est le piège du diable de penser que la validation est moins grave qu'une incapacité à ouvrir une base de données. Les deux cas ont le même impact - l'opération ne peut pas être terminée comme demandé.

Vous devez donc utiliser les objets de résultat pour les résultats et SOAP Défauts pour tout ce qui empêche un objet de résultat valide; y compris, mais sans s'y limiter, les erreurs, les échecs de validation, les avertissements, les défauts de bus, etc.).

Dans les jours précédant les exceptions, il n'y avait pas de choix et, par conséquent, de nombreuses API sont devenues incohérentes et la plupart des API différaient sur la façon de renvoyer une erreur. Cela a été (et est toujours) horrible, déroutant et ralentit souvent le développement, car vous devez rechercher comment chaque entrée d'API renvoie une erreur, et souvent comment décoder ou en savoir plus sur l'erreur.

1. Gérer la validation avec SOAPFaults/Exceptions est plus logique quand on y pense, et une fois que vous y avez pensé, c'est généralement plus facile. Vous devez concevoir la classe de défauts de validation afin qu'elle contienne suffisamment d'informations pour identifier les éléments incriminés d'une manière qui ne nécessite pas nécessairement la demande d'origine. De cette façon, vous pouvez commencer à gérer les erreurs de validation de manière plus générique.

2. Si l'objet de résultats contient des erreurs, elles ne peuvent appartenir qu'au domaine des résultats; par exemple Produit en rupture de stock parce que quelqu'un dans l'entrepôt ne peut pas compter est dans le domaine du contrôle des stocks.

3. Il n'est pas judicieux de faire la distinction entre une erreur critique et une erreur de validation, cela n'est pas, à mon avis, une comparaison valable car toute attribution de niveau de gravité est très subjective. Par exemple, dans un système fournissant des informations sur les produits chimiques à un pompier, critique signifie probablement que le camion en feu porte UN 1298 et UN 1436 et non une référence nulle lors de la tentative de chargement du graphique d'avertissement.

   Concevez les défauts pour qu'ils soient identifiés de manière concise et traités en conséquence. Assurez-vous qu'ils transmettent suffisamment d'informations. La catégorisation abrégée est quelque chose qui n'est pas nécessaire lorsque vous avez suffisamment d'informations parce que la faute se permettra d'être identifiée.

4. Les SOAPFaults transformés en exceptions sont le moyen le plus sûr d'avoir un échec rapide.

5. Meilleures pratiques, références, etc.

   • Gestion des exceptions dans un monde SOA: Ramesh Ranganathan

   • Quand les exceptions sont la règle: obtenir des architectures orientées services fiables et traçables

   • Meilleures pratiques sur SOAP Défauts

   • tilisez SOAP Défauts pour fournir le niveau de détail approprié au développeur au moment du développement et au client pendant que le service Web est en production.

   • Les services Web utilisent SOAP défauts pour signaler les cas de défaut aux clients. Les défauts peuvent être générés à partir du cadre SOAP dans un cas de non valide = SOAP messages, jetons de sécurité non valides ou ils peuvent être générés à partir de la logique métier du service elle-même

   • Si vous envoyez un message qui n'a pas réussi pour une raison quelconque, vous pouvez obtenir une réponse contenant un élément d'erreur SOAP, qui vous donne des informations d'état, des informations d'erreur, ou les deux). Il ne peut y avoir qu'un seul élément d'erreur SOAP dans un message, et il doit s'agir d'une entrée dans le corps SOAP. De plus, s'il y a un SOAP élément de défaut dans le corps SOAP, il ne peut y avoir aucun autre élément dans le corps SOAP. Cela signifie que lorsque vous ajoutez un SOAP élément de défaut, vous avez effectivement terminé la construction du corps SOAP.

   • Les messages d'erreur SOAP sont le mécanisme par lequel SOAP signalent les erreurs "en amont", aux nœuds plus tôt dans le chemin du message. C'est la mission de cette section de fournir une explication complète et détaillée des erreurs SOAP afin que vous puissiez les gérer de manière appropriée dans vos propres services Web.

Answer 3

Je pense que la réponse courte est d'utiliser une faute de savon, sauf si vous savez que le client sera équipé pour gérer une erreur renvoyée en conséquence. Je pensais également à l'analogie entre les exceptions et les résultats d'erreur, comme mentionné dans les autres réponses.

Il existe des zones grises qui pourraient à la fois être raisonnablement traitées comme des exceptions et comme des erreurs de résultat selon les besoins du client. Vous pouvez ensuite fournir un paramètre au service qui modifie la façon dont ces types d'erreur sont renvoyés. La valeur par défaut est d'utiliser une erreur SOAP, mais si le client définit le paramètre pour obtenir des résultats d'erreur, cela indique qu'il est disposé à gérer cela dans le cadre du résultat. Pour moi, les erreurs de validation se trouvent dans cette zone grise. Pour la plupart des clients, elles doivent être considérées comme des erreurs, mais si le client souhaite utiliser les données pour baliser l'interface utilisateur avec des erreurs de validation, le renvoi des erreurs de validation dans le cadre du résultat peut être plus utile.

Answer 4

La règle que je respecte dans la conception des services est la suivante:

• niveau métier réponse (même les exceptions métier) dans les objets de réponse
• niveau technique/intégration défauts dans Soap Fault

Le consommateur de services peut compter que toutes sortes de réponses métier viennent dans les objets de réponse et les présentent aux utilisateurs (professionnels) de service. Les défauts de savon sont utilisés uniquement lorsque la réponse de l'entreprise ne peut pas être fournie.

Les défauts de savon doivent déclencher un avertissement/une action d'assistance via la surveillance.