Restsharp: ResponseStatus - ошибка, если ответ 404 NotFound.

Я установил приложение Windows Forms для тестирования. Не могли бы вы подробнее рассказать об этой проблеме? Я не понимаю, что вы подразумеваете под "необщим"

Под «неуниверсальным» я имел в виду метод Execute в RestClient, который не принимает универсальный параметр:

IRestResponse Execute(IRestRequest request);

против:

IRestResponse<T> Execute<T>(IRestRequest request) where T : new();

Если это поможет, я решил обойти проблему, написав метод расширения IRestResponse, который использует Json.NET для десериализации свойства Content:

public static TResult Content<TResult>(this IRestResponse response)
{
    return JsonConvert.DeserializeObject<TResult>(response.Content);
}

Затем я мог бы использовать «неуниверсальный» метод Execute, чтобы сделать свой запрос и получить типизированный ответ с помощью моего метода расширения:

var resp = client.Execute(new RestRequest("some/resource"));

if (resp.ResponseStatus != ResponseStatus.Completed) { // Check whether request completed
     //Handle error
}

if (resp.StatusCode == HttStatusCode.NotFound) { // Check for 404
     //Handle 404
}

var result = resp.Content<SomeResult>();

Выполнение тех же действий с «универсальным» Execute:

var resp = client.Execute<SomeResult>(new RestRequest("some/resource"));

if (resp.ResponseStatus != ResponseStatus.Completed) {
     //This is reached even for 404 - I presume because of a failure during deserialization
}

//Handling 404 here isn't possible be cause it appears the request did not complete...
if (resp.StatusCode == HttStatusCode.NotFound) {
    //Handle 404
}

var result = resp.Data; // Data is null

У меня такая же проблема с v105.2.3, поэтому я изменил мои вызовы Execute <> на Execute и использовал предложенное выше предложение, которое разрешило проблему.

Проблема, по-видимому, связана с тем, что содержимое с сервера для ответа HTTP 500 представляет собой фрагмент HTML, который не может быть десериализован в мой тип с помощью сериализатора JSON, и поэтому я предполагаю, что ResponseStatus установлен на Ошибка как десериализация не удалась.

Текущая документация предполагает, что ResponseStatus устанавливается только для ошибок, связанных с сетью / подключением, но не для ошибок десериализации.

Что бы это ни стоило, я предлагаю, чтобы свойство Data генерировало исключение в случае сбоя десериализации, а не изменяло ResponseStatus с Completed на Error (хотя это может представлять критическое изменение для тех, кто ожидает, что он будет работать так, как он работает сейчас).

Все еще открыт? Это куда-нибудь денется? Похоже, к этому моменту нужно либо решить, либо прокомментировать и закрыть.

Думаю, это надо исправить. Предложение @simonob звучит очень разумно. Многие приложения возвращают дрянные ответы, которые мы не можем десериализовать, это вполне нормально.

Хорошо, что это на самом деле задумано. Я добавил возможность возвращать Завершено при сбое десериализации. Для обратной совместимости я должен сохранить текущее поведение как есть, но если вы установите для RestClient.FailOnDeserializationError значение false в следующей версии, вы получите его отсортированный.

Из любопытства, в чем причина такого поведения?
Мне кажется, что наиболее логичным поведением в случае, когда запрос успешно завершается и получает код состояния с сервера, но не удается десериализовать локально, было бы, чтобы IsSuccessful было false, а ResponseStatus = Completed.

В нынешнем состоянии, насколько я могу судить, нет способа определить, глядя на любое из этих свойств, не удалось ли запросу получить ответ от сервера или успешно завершился, но не удалось десериализовать. По сути, оба они, кажется, указывают на одно и то же, что делает одно из них избыточным.