public IActionResult CreateANewCar(Car entity)
{
...
}
[HttpPut("{id}")]
public IActionResult UpdateAnExistingCar(int id, Car entity)
{
...
}
[HttpDelete("{id}")]
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("application/json")]
public IActionResult PostJson(IEnumerable
Ok(new { Consumes = "application/json", Values = values });
[HttpPost]
[Consumes("application/x-www-form-urlencoded")]
public IActionResult PostForm([FromForm] IEnumerable
Ok(new { Consumes = "application/x-www-form-urlencoded", Values = values });
Еще одно преимущество маршрутизации связано с тем, что вам больше не придется жестко кодировать URL для других страниц в своем сайте. Записи в таблице маршрутов применяются для сопоставления с входящими запросами, а также для построения URL. При построении URL схема, хост и порт добавляются на основе значений текущего запроса.
Фильтры в ASP.NET Core запускают код до или после специфической фазы конвейера обработки запросов. Существуют встроенные фильтры для авторизации и кеширования, а также возможность назначения специальных фильтров. В табл. 29.7 описаны типы фильтров, которые могут быть добавлены в конвейер, перечисленные в порядке их выполнения.
Фильтры авторизации работают с системой ASP.NET Core Identity, чтобы предотвратить доступ к контроллерам или действиям, использовать которые пользователь не имеет права. Создавать специальные фильтры авторизации не рекомендуется, поскольку встроенные классы AuthorizeAttribute и AllowAnonymousAttribute обычно обеспечивают достаточный охват в случае применения ASP.NET Core Identity.
Код "перед" выполняется после фильтров авторизации и до любых других фильтров, а код "после" выполняется после всех остальных фильтров. Таким образом, фильтры ресурсов способны замкнуть накоротко целый конвейер запросов. Обычно фильтры ресурсов используются для кеширования. Если ответ находится в кеше, тогда фильтр может пропустить остаток конвейера.
Код "перед" выполняется немедленно перед выполнением метода действия, а код "после" выполняется сразу после выполнения метода действия. Фильтры действий могут замкнуть накоротко метод действия и любые фильтры, помещенные внутрь фильтров действий.
Фильтры исключений реализуют сквозную обработку ошибок в приложении. У них нет событий, возникающих до или после, но они обрабатывают любые необработанные исключения, сгенерированные при создании контроллеров, привязке моделей, запуске фильтров действий либо выполнении методов действий.
Фильтры результатов завершают выполнение экземпляра реализации IActionResult для метода действия. Распространенный сценарий применения фильтра результатов предусматривает добавление с его помощью информации заголовка в сообщение ответа HTTP.
