Под конфигурацией приложения обычно понимаются какие-либо настройки, применяемые, например, при запуске приложения. Это могут быть такие настройки, как строки подключения к базам данных, настройки оформления приложения, включение дополнительных опций и т. д.
ASP.NET Core Web API
Класс WebApplicationBuilder. Настройка приложения
Именно с создания экземпляра этого класса начинается выполнение приложения. В этой части мы рассмотрим некоторые из свойств класса WebApplicationBuilder.
Класс WebApplication. Запуск и остановка приложения, доступ к событиям жизненного цикла приложения
Класс WebApplication реализует сразу три интерфейса IHost, IApplicationBuilder и IEndpointRouteBuilder и используется для широкого круга задач — от запуска и остановки приложения, до настройки маршрутов, с которыми сопоставляются запросы пользователей, конвейера обработки запросов и получения доступа к настройкам приложения.
Файл Program.cs проекта ASP.NET Core Web API
Файл Program.cs – это главный файл нашего приложения с которого начинается абсолютно всё, что касается работы. В зависимости от того, какая версия платформы .NET выбрана при создании нового проекта, зависит содержимое этого файла.
Работа приложения ASP.NET Core. Веб-сервер Kestrel
Прежде, чем мы приступим к изучению «внутренностей» ASP.NET Core, стоит потратить немного времени, чтобы разобраться с тем, как в принципе работает любое приложение ASP.NET Core.
HTTP-кэширование в ASP.NET Core Web API
HTTP-кэширование (веб-кэширование), как и кэширование данных, является одним из способов повышения производительности веб-приложений. Управление HTTP-кэшированием ресурсов осуществляется с помощью заголовков запросов. Обычно выделяют два вида веб-кэшей – приватный (private cache) и кэш совместного использования (shared cache). Также, в различных источниках можно встретить такие названия как клиентский кэш, шлюзовый, прокси-кэш и так далее. Но, в любом случае, все эти виды кэшей так или иначе можно свести к первым двум видам: приватный (клиентский) кэш – это кэш, который доступен конкретному пользователю и хранится на его компьютере, а кэш совместного пользования, в свою очередь, может располагаться где-либо в Сети и быть доступным многим пользователям.
Что касается непосредственно ASP.NET Core, то здесь можно выделить два механизма HTTP-кэширования – это кэширование ответов (response caching) и кэширование выходных данных (output caching). Несмотря на то, что эти механизмы очень похожи между собой, всё же это два разных механизма кэширования, причем, если кэширование ответов — это довольно старый механизм кэширования, который появился ещё в ASP.NET Core 1.0 и используется до сих пор, то кэширование выходных данных — относительно новый механизм, появившийся в ASP.NET Core 7.0. И в этой статье мы попробуем разобраться в том, как работает http-кэширование в приложениях ASP.NET Core Web API и чем эти механизмы кэширования различаются друг от друга.
Централизованная обработка исключений в ASP.NET Core Web API
Обработка исключений позволяет нам избежать аварийного завершения работы приложения. Для обработки исключений в приложениях C#, обычно, используются блоки try...catch с ключевым словом final для того, чтобы очистить ресурсы приложения. Это стандартная практика обработки исключений, которая может также применяться и в приложениях ASP.NET Core Web API. Однако, платформа ASP.NET Core позволяет извлечь всю логику обработки исключений и сосредоточить её в одном централизованном месте, избежав тем самым использования блоков try…catch в действиях контроллера и обеспечить, при необходимости, единый формат сообщений о возникших исключительных ситуациях в приложении. Такой подход к обработке исключений в приложениях ASP.NET Core часто называют Global Exception Handling – глобальная обработка исключений, хотя, на мой взгляд, правильнее было бы назвать этот механизм так, как указано в заголовке — централизованная обработка исключений, так как всё же, рассматриваемые ниже способы обработки исключений помогают обработать не все возможные исключения в приложении.
Тестирование Web API. Использование http-файлов Visual Studio
При создании нового проекта ASP.NET Core Web API мы можем тестировать запросы к API различными способами, например, воспользоваться сторонними сервисами типа ReqBin, Postman и так далее. Вместе с тем, Visual Studio 2022 предоставляет достаточно удобный способ тестирования запросов API — использование http-файлов (файлов проекта с расширением .http).
Контроллеры Web API. Согласование содержимого и форматирование данных ответа
На сегодняшний день, практически форматом по умолчанию для отправки ответа клиенту сервером Web API считается JSON. Это действительно довольно популярный, лаконичный и простой формат обмена данными, который используется практически повсеместно. Когда мы создаем приложение ASP.NET Core Web API, то, по умолчанию, сервер также пытается сериализовать ответ в JSON. При этом, ASP.NET Core позволяет настраивать формат данных ответа и использовать, в том числе, для обмена данными XML. В этой части мы рассмотрим некоторые вопросы форматирования данных ответа в приложениях ASP.NET Core Web API.
Контроллеры Web API. Передача данных в контроллер через параметры запроса
Одним из способов передачи данных в контроллер, помимо параметров маршрута, является также использование параметров запроса в URL. Параметры запроса могут активно использоваться в проекте Web API, например, для определения пользователем фильтров данных, направления сортировки, постраничного вывода результатов и т.д. ASP.NET Core позволяет передавать с помощью параметров запроса как простые типы данных, так и сложные. Этот способ передачи данных в контроллер является одним из способов, используемых системой привязки модели в ASP.NET Core.