Язык программирования C#9 и платформа .NET5

public IActionResult ByMake(int makeId, string makeName)
{
  ViewBag.MakeName = makeName;
  return View(_repo.GetAllBy(makeId));
}
На заметку! Если метод действия не декорирован каким-либо атрибутом метода HTTP, то по умолчанию принимается метод 
GET
. Тем не менее, в веб-приложениях MVC непомеченные методы действий могут также реагировать на запросы 
POST
. По этой причине рекомендуется явно помечать все методы действий подходящим атрибутом метода HTTP.
  
Маршрутизация для служб API
 
Существенное различие между определениями маршрутов, которые применяются для приложений в стиле MVC, и определениями маршрутов, которые используются для служб REST, заключается в том, что в определениях маршрутов для служб не указываются методы действий. Методы действий выбираются на основе метода HTTP запроса (и необязательно типа содержимого), но не по имени. Ниже приведен код контроллера API с четырьмя методами, которые все соответствуют одному и тому же шаблону маршрута. Обратите внимание на атрибуты методов HTTP:
[Route("api/[controller]")]
[ApiController]
public class CarController : ControllerBase
{
<b>  [HttpGet(&quot;{id}&quot;)]</b>
  public IActionResult GetCarsById(int id)
  {
    ...
  }
<b>  [HttpPost]</b>
  public IActionResult CreateANewCar(Car entity)
  {
    ...
  }
<b>  [HttpPut(&quot;{id}&quot;)]</b>
  public IActionResult UpdateAnExistingCar(int id, Car entity)
  {
    ...
  }
<b>  [HttpDelete(&quot;{id}&quot;)]</b>
  public IActionResult DeleteACar(int id, Car entity)
  {
    ...
  }
}
Если метод действия не имеет атрибута метода HTTP, то он трактуется как конечная точка приложения для запросов 
GET
. В случае если запрос соответствует маршруту, но метод действия с корректным атрибутом метода HTTP отсутствует, тогда сервер возвратит ошибку 404 (не найдено).
На заметку! Инфраструктура ASP.NET Web API позволяет не указывать метод HTTP для метода действия, если его имя начинается с 
Get
, 
Put
, 
Delete
 или 
Post
. Следование такому соглашению обычно считалось плохой идеей и в ASP.NET Core оно было удалено. Если для метода действия не указан метод HTTP, то он будет вызываться с применением НТТР-метода 
GET
.
 
Последним селектором конечных точек для контроллеров API является необязательный атрибут 
Consumes
, который задает тип содержимого, принимаемый конечной точкой. В запросе должен использоваться соответствующий заголовок 
content-type
, иначе будет возвращена ошибка 415 Unsupported Media Туре (неподдерживаемый тип носителя). Следующие два примера конечных точек внутри одного и того же контроллера проводят различие между JSON и XML:
[HttpPost]
[Consumes(&quot;application/json&quot;)]
public IActionResult PostJson(IEnumerable&lt;int&gt; values) =&gt;
  Ok(new { Consumes = &quot;application/json&quot;, Values = values });
[HttpPost]
[Consumes(&quot;application/x-www-form-urlencoded&quot;)]
public IActionResult PostForm([FromForm] IEnumerable&lt;int&gt; values) =&gt;
  Ok(new { Consumes = &quot;application/x-www-form-urlencoded&quot;, Values = values });
  
Перенаправление с использованием маршрутизации
 
 Еще одно преимущество маршрутизации связано с тем, что вам больше не придется жестко кодировать URL для других страниц в своем сайте. Записи в таблице маршрутов применяются для сопоставления с входящими запросами, а также для построения URL. При построении URL схема, хост и порт добавляются на основе значений текущего запроса.
  
Фильтры
 
Фильтры в ASP.NET Core запускают код до или после специфической фазы конвейера обработки запросов. Существуют встроенные фильтры для авторизации и кеширования, а также возможность назначения специальных фильтров. В табл. 29.7 описаны типы фильтров, которые могут быть добавлены в конвейер, перечисленные в порядке их выполнения.
  
Фильтры авторизации
 
Фильтры авторизации работают с системой ASP.NET Core Identity, чтобы предотвратить доступ к контроллерам или действиям, использовать которые пользователь не имеет права. Создавать специальные фильтры авторизации не рекомендуется, поскольку встроенные классы 
AuthorizeAttribute
 и 
AllowAnonymousAttribute
 обычно обеспечивают достаточный охват в случае применения ASP.NET Core Identity.
  
Фильтры ресурсов
 
Код "перед" выполняется после фильтров авторизации и до любых других фильтров, а код "после" выполняется после всех остальных фильтров. Таким образом, фильтры ресурсов способны замкнуть накоротко целый конвейер запросов. Обычно фильтры ресурсов используются для кеширования. Если ответ находится в кеше, тогда фильтр может пропустить остаток конвейера.
  
Фильтры действий
 
Код "перед" выполняется немедленно перед выполнением метода действия, а код "после" выполняется сразу после выполнения метода действия. Фильтры действий могут замкнуть накоротко метод действия и любые фильтры, помещенные внутрь фильтров действий.
  
Фильтры исключений
 
Фильтры исключений реализуют сквозную обработку ошибок в приложении. У них нет событий, возникающих до или после, но они обрабатывают любые необработанные исключения, сгенерированные при создании контроллеров, привязке моделей, запуске фильтров действий либо выполнении методов действий.