TL; DR;
«Мне нравится, как мой сгенерированный клиент AutoRest десериализует мои основные сущности при работе с 200 сценариями ... но ДОЛЖЕН ли я вручную анализировать 400 сценариев?», Сказал ленивый программист
ОПИСАНИЕ:
Итак, у меня есть API (Web API 2), и я делаю все стандартные вещи ... используя POCO, которые реализуют IValidatable
в дополнение к проверке на уровне свойств с использованием System.Data.DataAnnotations
, мой Web API возвращает 400 ошибок, таких как это (просто пример):
if (!ModelState.IsValid)
{
return BadRequest(ModelState);
}
И, при необходимости, я использую SwaggerResponse
атрибуты, и мой swagger.json документируется таким образом, чтобы мой сгенерированный клиент знал, что 400 является жизнеспособным ответом.
Теперь, мои модульные тесты, которые непосредственно создают экземпляры контроллеров API, я намеренно пытаюсь проверить на недопустимое состояние модели. Я могу взять ответ IHttpActionResult
от вызова контроллера, привести его к InvalidModelStateResult
и выполнить итерацию по Словарь ModelState.
Но я нахожу написание чего-то похожего для моих «производственных HTTP-вызовов» с реальным HTTP-клиентом - не так просто.
Итак, ближе к сути моего вопроса:
Есть ли предпочтительный метод десериализации InvalidModelStateResult
?
Итак, при взаимодействии моего API с реальными вызовами http ... через Microsoft.Rest.ServiceClient
, JSON, который я получаю, имеет немного другую форму.
Пример кода контроллера MVC, взаимодействующего с моим API:
HttpOperationResponse resp = await client.SpecialLocations.PatchByIdWithHttpMessagesAsync(id, locationType, "return=representation");
if (!resp.Response.IsSuccessStatusCode)
{
//The JSON returned here is not really in the form of an InvalidModelStateResult
ViewBag.Error = await resp.Response.Content.ReadAsStringAsync();
return View(locationType);
}