J'ai un service de repos consommé par un client .NET WCF.
Lorsqu'une erreur est rencontrée, le service de repos renvoie une mauvaise demande HTTP 400 avec le corps de réponse contenant des détails sérialisés JSON.
Si j'exécute la demande à l'aide de Fiddler, JavaScript ou directement à partir de C #, je peux facilement accéder au corps de réponse lorsqu'une erreur se produit.
Cependant, j'utilise un code de la WCF Y a-t-il un moyen d'obtenir le corps de réponse lorsque je reçois cette erreur?
Je me rends compte qu'il existe une charge de différentes manières de le faire à l'aide de .NET et qu'il existe d'autres moyens d'obtenir la réponse des erreurs. Ils sont utiles à savoir mais ne répondent pas à cette question.
Les services de repos que nous utilisons changeront et lorsqu'ils effectuent les interfaces complexes sont mises à jour. Utilisation de la section Y a-t-il un moyen d'obtenir le corps de réponse pour un état HTTP d'erreur lors de l'utilisation de canaux WCF? canalelfactory avec 6 interfaces assez complexes. L'exception projetée par ce proxy est toujours une Protocolexception , sans détails utiles.
canalelysory avec les nouvelles interfaces signifie que nous obtiendrons des exceptions de temps (plutôt que d'exécuter) et de les rendre beaucoup plus faciles à maintenir et à mettre à jour le code.
6 Réponses :
N'utilisez pas de canalsiorysory :-) Sérieusement. Pourquoi créeriez-vous une interface de repos, puis utilisez le proxy client WCF. Quel est l'avantage d'utiliser le service de repos? Pourquoi ne pas simplement utiliser wshttpbinding? Avec la classe httpClient à partir du kit de démarreur de repos, vous pouvez effectuer des demandes HTTP standard, puis désérialiser la réponse à l'aide du DatacontractSerializer.
E.g. P>
var httpClient = new HttpClient();
var content = httpClient.Get("http://example.org/customer/45").Content;
var customer = content.ReadAsDataContract<Customer>()
J'aime votre approche simple-is-meilleure, mais nous avons un grand nombre d'interfaces, et presque toutes les méthodes prennent du contenu post complexe. La simplicité de code de la mise en œuvre de la proxy de CODE> CYNELYLYelfactory nous permet d'économiser une énorme complexité du code. Je sais que cela peut être fait de votre chemin, mais ce que je veux vraiment savoir, c'est: pouvons-nous obtenir le détail d'erreur si nous le faisons le canalelfactory chemin?
Vous pouvez essayer de lancer une
C'est exactement ce que le service fait - les détails que JSON soient sérialisés dans le corps de la réponse HTTP. Le problème est que la canalisation change d'une exception sans ces détails pour un statut d'en-tête HTTP autre que 200. Le service fonctionne, c'est la mise en œuvre du client de WCF qui est le problème.
Mes deux cents sont que la WCF est bonne pour exposer la même classe en utilisant de nombreuses liaisons différentes. Lors de la communication avec C #, utilisez une liaison de savon qui convient aux informations d'exception. Si vous devez utiliser la liaison du style de repos, vous pouvez utiliser un simple WebRequest pour appeler le service et utiliser le sérialisateur JSON pour désexerez les résultats. Cela vous donnera également un accès direct au code de réponse.
Vous pouvez récupérer les détails de l'exception comme ci-dessous:
Exception innerException = exception.InnerException;
WebException webException = innerException as WebException;
HttpWebResponse response = webException.Response as HttpWebResponse;
string statusDescription = response.StatusDescription;
HttpStatusCode statusCode = response.StatusCode;
L'approche décrite par User653761 fonctionne pour moi; Après avoir eu accès à l'objet Je suppose que cela fonctionnerait pour tout ce que wcf peut sérialiser si vous utilisez le bon sérialiseur, n'a pas encore testé la performance (encore). httpwebresponse , je peux utiliser la classe datacontractSerializer comme ceci:
Le InnerException du protocolexception sera un WebException .
Vous pouvez obtenir le httpwebrevonse à partir de celui-ci et appelez getResponsestream pour lire le corps de réponse réelle. (N'oubliez pas de chercher au début du flux avant de lire).
Lire votre explication, on dirait que vous n'avez pas de contrôle sur le service de repos lui-même, est-ce correct?
En fait, dans ce cas, nous le faisons, mais il est difficile de changer. Notre problème est la complexité - la voie canalisatrice de la WCF donne une façon très agréable de gérer cela avec des interfaces. La chose agaçante est que cela lance le corps de réponse lorsque le statut d'en-tête HTTP est autrefois 200. Lorsque nous obtenons une erreur du service de repos, il renvoie un statut HTTP 400 ou 500 avec des détails dans le corps.