Défaut SOAP ou objet de résultats?

Question

J'avais une discussion à ce sujet avec un collègue et nous n'avons pas pu nous entendre, alors je voulais avoir votre avis. J'ai mes propres opinions là-dessus, mais je ne vais pas gâcher ça pour vous.

Quand dois-je être un SOAP retournaient faute et quand dois-je être un objet retournaient résultat qui contient des informations d'erreur? Supposons que cela concerne un service Web générique qui peut être utilisé par divers systèmes (.NET, Java, etc.). 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 d'un défaut?
2. Devrait-il y avoir une combinaison de fautes (pour des cas très exceptionnels) et l'objet de résultats (pour les erreurs "attendues")?
3. Comment regrouperiez-vous les fautes SOAP (critique [référence null] vs validation [code postal incorrect])?
4. Fail-rapide vs avoir à se rappeler de vérifier l'erreur
5. les meilleures pratiques, modèles, normes, etc.

Liens vers des articles sont valables. Même s'il semble que je veux votre opinion, s'il vous plaît s'en tenir aux faits (x est mieux à cause de y et z ...)

Answer 1

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

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

1. Le client a besoin d'énumérer manuellement et gérer vos codes d'erreur par rapport permettant au code stub pour générer et lancer une exception de la type approprié. L'utilisation de codes d'erreur empêche le client d'utiliser des techniques orientées objet comme la gestion des exceptions par superclasse.

2. Si vos codes d'erreur ne font pas partie 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) sont auto-documentées. Les messages d'erreur peuvent contenir un contexte spécifique à une 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 invalide réel et une raison. Si vous retournez un résultat avec un code d'erreur et une chaîne opaque, le client a peu de choix mais de transmettre votre message d'erreur à l'utilisateur, qui rompt l'internationalisation, la cohérence de l'interface utilisateur, etc.

Pour répondre à vos besoins spécifiques questions:

1. Une erreur de validation est une erreur. 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 succès 400 avec une réponse inattendue.Non. Les API doivent fournir des interfaces de signalisation d'erreur cohérentes. La conception WSDL est une conception d'API. Forcer le client à implémenter deux gestionnaires d'erreurs distincts ne facilite pas la vie du client. La conception de l'erreur doit refléter votre modèle de demande/réponse et afficher des informations appropriées à l'abstraction du service. Ne pas concevoir une faute NullReference; concevoir un XYZServiceRuntimeFault. Si les clients fournissent fréquemment des requêtes non valides, créez un InvalidRequestFault avec les sous-classes appropriées pour que les clients puissent rapidement déterminer où se trouvent les données non valides.

Answer 2

Un objet de résultat 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, alors c'est un exemple de quand vous pouvez avoir le drapeau "isError"; sinon vous ne pouvez pas parce qu'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 propre piège des démons de penser que la validation est moins sévère que l'impossibilité d'ouvrir une base de données. Les deux cas ont le même impact - l'opération ne peut pas être complétée comme demandé. Vous devez donc utiliser les objets de résultat pour les résultats et les fautes SOAP pour tout ce qui empêche un objet de résultat valide; 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 ont différé sur la façon de renvoyer une erreur. Il était (et est toujours) horrible, déroutant et ralentit souvent le développement car vous devez rechercher comment chaque entrée de l'API renvoie une erreur, et souvent comment décoder ou en savoir plus sur l'erreur.

1. Pour gérer la validation avec SOAPFaults/exceptions est plus logique quand on y pense, et une fois que vous avez pensé à ce sujet est généralement plus facile. Vous devez concevoir la classe d'erreur de validation afin qu'elle contienne suffisamment d'informations pour identifier les éléments incriminés d'une manière ne nécessitant 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 se situer que dans le domaine des résultats; par exemple Produit en rupture de stock parce que quelqu'un dans le wharehouse ne peut pas compter est dans le domaine du contrôle d'inventaire.

3. Il n'est pas judicieux de faire la distinction entre une erreur critique et une erreur de validation, ce qui, à mon avis, n'est pas une comparaison valable, car toute assignation du 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 & UN 1436 et pas une référence nulle lors de la tentative de chargement du graphique d'avertissement.

   Concevoir les défauts afin de permettre leur identification concise et leur traitement en conséquence. Assurez-vous qu'ils transmettent suffisamment d'informations. La catégorisation arbitraire est quelque chose qui n'est pas nécessaire lorsque vous avez suffisamment d'informations parce que la faute va se permettre d'être identifiée.

4. Les SOAPFaults transformées en exceptions sont le moyen le plus sûr d'avoir un fail-fast.

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

   • Managing Exceptions in a SOA world: Ramesh Ranganathan

   • When Exceptions Are the Rule : Achieving reliable and traceable service-oriented architectures

   • Best practices on SOAP Faults

   • Use SOAP Faults to deliver the appropriate level of detail to the developer at development time, and to the customer while the Web service is in production.

   • Web services use SOAP faults to report fault cases back to clients. The faults can be generated from the SOAP framework in a case of invalid SOAP messages, invalid security tokens or they can be generated from the service business logic itself

   • SOAP fault messages are the mechanism by which SOAP applications report errors “upstream,” to nodes earlier in the message path. It's the mission of this section to provide a full and detailed explanation of SOAP faults so that you can handle them appropriately in your own Web services.

Answer 3

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

Il existe des zones grises qui peuvent être raisonnablement traitées comme des exceptions et comme des erreurs de résultat en fonction des 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, il indique qu'il est prêt à gérer cela dans le cadre du résultat. Pour moi, les erreurs de validation sont dans cette zone grise. Pour la plupart des clients, ils doivent être considérés comme des erreurs, mais si le client souhaite utiliser les données pour baliser l'interface utilisateur avec des erreurs de validation, il peut être plus utile de renvoyer les erreurs de validation dans le résultat.  

Answer 4

La règle que je suis dans la conception de services est:

• niveau des entreprises réponse (même des exceptions d'affaires) en réponse objets
• niveau technique/intégration défauts dans Fault Savon

Le consommateur de service peut compter sur le fait que tout type de réponse d'entreprise est livré dans des objets de réponse et le présente au service (busi utilisateurs). Les fautes de savon sont utilisées 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 de support via la surveillance.