Непонятные сообщения о неправильном запросе от Asp. Net Связывание базовой модели API при ошибке JSON синтаксического анализатора (например, несоответствие типов)? - PullRequest
0 голосов
/ 18 февраля 2020

Если я отправляю тело JSON с неправильным типом (например, целое число, где строка ожидается в модели с Asp. Net Core), я получаю следующее сообщение:

"$. Name": ["Не удалось преобразовать значение JSON в System.String. Путь: $ .name | LineNumber: 1 | BytePositionInLine: 11." ]

Эта информация не очень понятна для случайного пользователя веб-интерфейса. Кроме того, если та же ошибка произойдет с enum, она также приведет к утечке информации о полностью определенном имени enum (включая пространство имен) и будет даже более бессмысленной для пользователя, чем System.String.

. Есть ли лучший способ справиться с этим в WebApi? Например, чтобы изменить все сообщения на общий c Value was not of expected type или что-то в этом роде?

Я знаю два возможных решения, но оба довольно громоздки:

  1. Все модели должны принять строку (хотя мы все равно получим строку со строкой, но она по крайней мере более или менее понятна) или объект (если это возможно). Тогда все проверки и сопоставления должны быть выполнены вручную
  2. Завершение конвертера для каждого типа, используемого в модели, и предоставление его в WebApi для использования

Я действительно надеюсь, что есть лучшее способ, который позволяет нам, например, «поймать» исключение из синтаксического анализатора или унаследовать от преобразователя по умолчанию и т. д. c.

Ответы [ 2 ]

1 голос
/ 07 апреля 2020

Если вы используете Newtonsoft Json, используйте эту настройку в Startup.cs. Это выдаст «Введен неверный ввод».

.AddNewtonsoftJson(options => 
{
    options.AllowInputFormatterExceptionMessages = false;
});
0 голосов
/ 18 февраля 2020

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

Ваша версия выпуска должна скрываться все эти детали и возвращают какую-то 4XX.

Это означает, что каждый публикуемый c API должен выглядеть примерно так:

public IActionResult MyApiFunction()
{
 try
 {
    ... do something
 }
 catch(Exception ex)
 {
   ... do some logging
   return BadRequest();
 }
}

Суть в том, что пользователь API не следовал указаниям c, поэтому он был плохой запрос, конец.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...