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

Троелсен Эндрю

[HttpGet("{id?}")]

public IActionResult Delete(int? id)

{

...

}

[HttpPost("{id}")]

public IActionResult Delete(int id, Car recordToDelete)

{

...

}

}

Маршруты можно перезапускать с использованием методов HTTP; понадобится просто предварить

шаблон маршрута символом прямой косой черты (

/

), как демонстрируется в следующем примере:

[HttpGet("/[controller]/[action]/{makeId}/{makeName}")]

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

{

[HttpGet("{id}")]

public IActionResult GetCarsById(int id)

{

...

}

[HttpPost]

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<int> values) =>

Ok(new { Consumes = "application/json", Values = values });

[HttpPost]

[Consumes("application/x-www-form-urlencoded")]

public IActionResult PostForm([FromForm] IEnumerable<int> values) =>

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.

Фильтры ресурсов

Код "перед" выполняется после фильтров авторизации и до любых других фильтров, а код "после" выполняется после всех остальных фильтров. Таким образом, фильтры ресурсов способны замкнуть накоротко целый конвейер запросов. Обычно фильтры ресурсов используются для кеширования. Если ответ находится в кеше, тогда фильтр может пропустить остаток конвейера.