2010-06-22 2 views
0

Je développe des services web SOAP en utilisant Ruby on Rails et je considère comment gérer les défaillances génériques. Ces erreurs génériques sont applicables à toutes les méthodes au sein du service et sont les suivants: -Quelle est la «meilleure pratique» pour les serveurs SOAP d'implémenter la notification d'erreur?

  • manquant élément de demande
  • élément d'authentification manquant (personnalisé)
  • détails d'authentification non valide

je peux intercepter ces erreurs au sein de mon contrôleur avant d'appeler la méthode appropriée et répondre de manière appropriée. Ma question est de savoir quelle implémentation est la plus facile à gérer du point de vue du client. Mes options pour gérer ces erreurs semblent être les suivantes. Soulevez une exception et laissez le service SOAP générer un SoapFault. Ce serait bien sauf que j'ai peu de contrôle sur la structure du message contenu dans la faute SOAP.

  • Renvoyer une réponse Http 400 avec une structure de données convenue pour indiquer le message d'erreur. Cette structure ne serait cependant pas définie dans le WSDL.
  • Inclure un élément d'état dans toutes les réponses, qu'il soit réussi ou non, et que cet élément d'état comprenne un code et un tableau de données d'erreur (y compris les messages d'erreur). L'option trois semble être la meilleure solution mais elle est aussi la plus sujette à l'implémentation car l'implémentation des services web dans ROR m'empêche de l'implémenter de manière générique et chaque méthode devient responsable de vérifier le résultat du vérifie et rend une réponse appropriée. Certes, il s'agirait d'un appel à une seule fonction et d'un retour en cas d'échec, mais il dépend du développeur de se souvenir de le faire au fur et à mesure que nous ajoutons d'autres options. J'apprécie que la plupart des développeurs ROR disent que cela devrait être implémenté comme un service REST et je suis d'accord, en fait nous avons déjà des services REST pour le faire mais la propagation de SOAP dans le monde de l'entreprise, et son impressionnant support d'outils signifie que nous devons fournir des services SOAP pour rester compétitifs. Selon votre expérience, quelle serait la mise en œuvre la plus simple à gérer pour les clients? Cela dépend-il des bibliothèques/langue du processus client? Un SoapFault serait le moyen préféré de signaler des erreurs.

  • Répondre

    0

    SoapFaults peut contenir des informations supplémentaires dans son élément <detail>. L'avantage d'un SoapFault sur certains éléments d'état est que l'appelant peut utiliser la gestion des exceptions standard, au lieu de vérifier un certain champ d'état.

    Questions connexes