Erste Fehlerdetails von WCF REST

Question

Ich habe einen REST-Dienst von einem .NET WCF-Client verbraucht wird.

Wenn ein Fehler der REST-Dienst auftritt gibt eine HTTP 400 Bad Request mit dem Antworttext enthält JSON Details serialisiert.

Wenn ich die Anfrage ausführen mit Fiddler, Javascript oder direkt aus C # ich einfach den Antworttext zugreifen kann, wenn ein Fehler auftritt.

Allerdings bin ich ein WCF ChannelFactory mit 6 recht komplexen Schnittstellen. Die Ausnahme von diesem Proxy geworfen ist immer ein ProtocolException, ohne nützliche Details.

Gibt es eine Möglichkeit, die Antwort Körper zu bekommen, wenn ich diesen Fehler?

---

Aktualisieren

Ich stellt fest, dass es eine Last von verschiedenen Möglichkeiten ist dies mit .Net zu tun, und dass es andere Möglichkeiten, um die Fehlerreaktion zu erhalten. Sie sind nützlich zu wissen, aber nicht diese Frage beantworten.

Der REST-Service werden wir ändern verwenden und wenn sie die komplexen Schnittstellen tun aktualisiert. Mit Hilfe des ChannelFactory mit den neuen Schnittstellen bedeuten, dass wir die Kompilierung bekommen (statt Laufzeit) Ausnahmen und machen diese viel einfacher, den Code zu pflegen und zu aktualisieren.

Gibt es eine Möglichkeit, den Antworttext für einen Fehler HTTP-Status zu erhalten, wenn WCF-Kanäle verwenden?

Answer 1

Verwenden Sie Channel nicht :-) Aber im Ernst. Warum würden Sie eine REST-Schnittstelle erstellen und dann den WCF-Client-Proxy verwenden. Was ist der Vorteil des REST-Service zu verwenden? Warum nicht einfach wsHttpBinding benutzen? Mit der Httpclient-Klasse aus der REST Starter-Kit können Sie Standard-HTTP-Anforderungen machen und dann Deserialisieren die Antwort der DataContractSerializer verwendet wird.

z.

var httpClient = new HttpClient();
var content = httpClient.Get("http://example.org/customer/45").Content;
var customer = content.ReadAsDataContract<Customer>()

Answer 2

Sie können die Ausnahme Detail abrufen wie folgt:

                Exception innerException = exception.InnerException;
                WebException webException = innerException as WebException;
                HttpWebResponse response = webException.Response as HttpWebResponse;
                string statusDescription = response.StatusDescription;
                HttpStatusCode statusCode = response.StatusCode;

Answer 3

Die InnerException des ProtocolException wird ein WebException sein. Sie können die HttpWebResponse aus, dass bekommen und GetResponseStream rufen den tatsächlichen Antworttext zu lesen. (Denken Sie daran, zu Beginn des Stroms zu suchen, vor dem Lesen).

var webException = (WebException) protocolException.InnerException;
var response = (HttpWebResponse) webException.Response;
var responseStream = response.GetResponseStream()
responseStream.Seek(0, SeekOrigin.Begin);
var reader = new StreamReader(responseStream);
var responseContent = reader.ReadToEnd();

Answer 4

Sie könnten versuchen, ein werfen WebProtocolException aus dem Dienst. Auf diese Weise der Fehlerdetails sollten im Körper der HTTP-Antwort enthalten sein. Werfen Sie einen Blick auf diesen Artikel:

effektive Fehlerbehandlung mit WCF & REST

Answer 5

Mein zwei Cent ist, dass WCF gut ist die gleiche Klasse mit vielen verschiedenen Bindungen an auszusetzen. Wenn mit C # in Verbindung steht, verwendet, um ein SOAP-Bindung, die gut in Ausnahmeinformationen ist. Wenn Sie den REST-Stil Bindung verwenden müssen, können Sie eine einfache WebRequest verwenden, den Dienst zu rufen und die JSON Serializer die Ergebnisse deserialisiert verwenden. Dies wird Ihnen auch einen direkten Zugang zum Antwortcode geben.

Answer 6

Der Ansatz beschrieben von user653761 Werken für mich; nach Zugang zum HttpWebResponse Objekt mit ich die DataContractSerializer Klasse wie folgt verwenden können:

var serializer = new DataContractSerializer(typeof(MyDataContractType));
var deserialized = 
    (serializer.ReadObject(httpWebResponse.GetResponseStream()) as MyDataContractType);

// ...

Ich denke, das für alles funktionieren wurde, dass WCF serialisiert werden kann, wenn Sie die richtigen Serializer verwenden, nicht Test für Leistung (noch) nicht.