Проверка ввода API на основе входного параметра
В моем контроллере у меня есть что-то вроде этого:
public async Task<Teacher?> GetTeacher(string id){}
Все, что я хочу сделать, это добавить что-то вроде BadRequest() или любую другую подходящую вещь для id проверки входного параметра.
и логика примерно такая:
if (id == "nah")
{
return BadRequest();
}
Что ж, проблема, с которой я столкнулся, заключается в том, что мой контроллер строго типизирован для Task<Teacher?>, и это нормально, когда я нахожу результат и возвращаю его этого типа, но он не будет компилироваться/не может сейчас привести, если у меня есть return BadRequest();
Итак, каков простой способ выполнить такую суперпростую проверку параметров?
Просто заставьте его возвращать ActionResult<T>, например (в вашем асинхронном случае Task<ActionResult<Teacher?>>
@devlincarnate «Или используйте наследование».. Нееет
@flackoverstow - почему неееет?
Ответы 2
С помощью WebAPI2, аннотируя свой метод с помощью [HttpGet("/GetTeacher/{id:string})"], вы можете напрямую добавить некоторую проверку — также см. возможность регулярного выражения в первой ссылке ниже, которая может помочь вам с более сложной проверкой. Вы можете попытаться изменить тип возвращаемого значения на IActionResult и возвращать что-то вроде Ok(FoundTeacher) в случае успеха, возвращая BadRequest при ошибке проверки.
Ограничения маршрутов в WebAPI2 - MSDC
Типы возвращаемых значений в WebAPI — MSDC
Хорошие варианты. буду изучать ссылки
Обратите внимание, что ограничения маршрута приведут к ошибке 404 для несовпадающих запросов. Другими словами, у вас может быть два маршрута «/{id:int}» и «/{name}». Второй маршрут будет использоваться только для нечисловых запросов.
Я решаю эту ситуацию следующим образом:
Создайте класс ошибок:
public class PersistantEntity
{
public ModelStateDictionary Errors { get; set; }
}
Это не обязательно типа ModelStateDictionary. Используйте тот тип, который лучше всего подходит для ваших ошибок.
И тогда ваш класс Teacher сможет наследовать класс PersistentEntity:
public class Teacher : PersistantEntity
{
}
И затем вы можете сослаться на это в контроллере с помощью:
model.Errors = new ModelStateDictionary();
//do something with model.Errors
И вы просто вернете model (типа Teacher) из своего контроллера, а затем сделаете все, что угодно с model.Errors во всем, что обрабатывает возврат.
Лично я выполняю проверку методом, содержащимся в модели, а не в контроллере. Но затем я вызываю его из контроллера с помощью:
model.Validate();
//then do something with model.Errors
Хорошая идея . У меня просто нет модельного класса. Это просто класс POCO DTO и входной параметр.
Можно ли сделать
BadRequest()собственностью или коллекциейTeacher? Или использовать наследование, чтобыTeacherнаследовал классBadRequest?