Упражнение. Создание проекта Функций Azure

Вашему веб-приложению со списком покупок требуется API. В этом упражнении вы создаете и запускаете API с помощью проекта Функции Azure. Затем вы расширяете API с помощью новой функции с помощью расширения Функции Azure для Visual Studio.

В этом упражнении выполните следующие действия.

1. Создание ветви при подготовке к внесению изменений в веб-приложение
2. Изучение проекта функций Azure.
3. Создание функции HTTP GET
4. Замена начального кода функции на логику для получения продуктов
5. Настройка веб-приложения для направления HTTP-запросов к API через прокси
6. Запуск API и веб-приложения

Получение приложения-функции

Теперь вы добавите API и подключите его к интерфейсным приложениям. Проект API включает неполный проект Функций Azure, поэтому давайте завершим это сейчас.

Создание ветви API

Прежде чем вносить в приложение изменения, рекомендуется создать для изменений новую ветвь. Вы готовы завершить API для приложения, поэтому создайте ветвь в Git с именем API.

Завершение API Функций Azure

Проект API содержит проект Функций Azure, а также три функции.

Ваш API включает маршруты для управления продуктами в списке покупок, но не имеет маршрута для получения продуктов. Давайте добавим следующее.

Создание функции HTTP GET

1. В Visual Studio щелкните проект API правой кнопкой мыши и выберите пункт "Добавить>новый элемент".

   

2. В диалоговом окне "Добавление нового элемента" выберите функцию Azure.

   

3. Введите ProductsGet.cs в качестве имени файла функции.

4. Выберите триггер Http в качестве типа функции.

5. Выберите "Анонимный" в раскрывающемся списке в поле уровня авторизации .

   

6. Нажмите кнопку "Добавить".

Вы дополнили приложение функций Azure функцией получения своих продуктов.

Настройка метода HTTP и конечной точки маршрута

Обратите внимание, что метод Run только что созданного C# класса имеет атрибут HttpTrigger для первого аргумента HttpRequest. Этот атрибут определяет уровень доступа функции, а также методы HTTP для прослушивания и конечную точку маршрута.

Конечная точка маршрута по умолчанию означаетnull, что конечная точка использует значение атрибутаFunctionName.ProductsGet Route Задание свойства для "products" переопределения поведения по умолчанию.

В настоящее время ваша функция вызывается при HTTP-запросе GET к продуктам. Ваш метод Run будет выглядеть следующим образом:

[FunctionName("ProductsGet")]
public static async Task<IActionResult> Run(
    [HttpTrigger(AuthorizationLevel.Anonymous, "get", "post", Route = null)] HttpRequest req,
    ILogger log)

Обновление логики маршрута

Текст Run метода выполняется при выполнении функции.

Чтобы получить продукты, необходимо обновить логику в методе Run . В файле ProductData.cs есть логика доступа к данным в виде класса с именем ProductData с доступом через внедрение зависимостей в качестве интерфейса IProductData. Интерфейс имеет метод на нем GetProducts, который возвращает Task<IEnumerable<Product> асинхронно возвращает список продуктов.

Теперь измените конечную точку функции, чтобы она возвращала продукты.

1. Откройте ProductsGet.cs.

2. Замените его содержимое на следующий код:

   using Microsoft.AspNetCore.Http;
   using Microsoft.AspNetCore.Mvc;
   using Microsoft.Azure.WebJobs;
   using Microsoft.Azure.WebJobs.Extensions.Http;
   using System.Threading.Tasks;
   
   namespace Api;
   
   public class ProductsGet
   {
       private readonly IProductData productData;
   
       public ProductsGet(IProductData productData)
       {
           this.productData = productData;
       }
   
       [FunctionName("ProductsGet")]
       public async Task<IActionResult> Run(
           [HttpTrigger(AuthorizationLevel.Anonymous, "get", Route = "products")] HttpRequest req)
       {
           var products = await productData.GetProducts();
           return new OkObjectResult(products);
       }
   }
   

В предыдущих изменениях класс превратился из статического в класс экземпляра. Вы добавили интерфейс в конструктор, чтобы платформа внедрения зависимостей может внедрить ProductData класс. Наконец, вы настроили функцию Run для возврата списка продуктов при вызове.

Локальная настройка общего доступа к ресурсам независимо от источника (CORS)

При публикации в Статические веб-приложения Azure вам не нужно беспокоиться о совместном использовании ресурсов между источниками (CORS). Служба статических веб-приложений Azure автоматически настроит ваше приложение так, чтобы оно могло взаимодействовать с вашим API в Azure через обратный прокси-сервер. Но при локальном запуске CORS необходимо настроить так, чтобы ваше веб-приложение могло взаимодействовать с API.

Для этого Функции Azure должны предлагать возможность разрешать вашему веб-приложению отправлять HTTP-запросы к API на вашем компьютере.

1. Откройте файл с именем launchSettings.json в папке "Свойства " проекта API .

   • Если такой файл не существует, создайте его.

2. Обновите содержимое файла:

   {
       "profiles": {
           "Api": {
               "commandName": "Project",
               "commandLineArgs": "start --cors *"
           }
       }
   }
   

Запуск API и веб-приложения

Теперь проверим, как ваше веб-приложение и проект Функций Azure работают вместе.

1. В Visual Studio щелкните правой кнопкой мыши решение ShoppingList .

2. Выберите "Настройка запускаемых проектов".

3. Выберите параметр "Несколько запускаемых проектов ".

4. Установите Api и Client, чтобы Start было их Action, а затем выберите Ok.

5. Запустите отладчик.

Перейдите к своему приложению.

Теперь посмотрим, как ваше приложение выполняется локально, используя API Функций Azure.

Найдите веб-приложение (например, https://localhost:44348/).

Вы собрали приложение, и теперь оно работает локально, отправляя HTTP-запросы GET к вашему API.

Теперь отключите свое запущенное приложение и API, отключив отладчик в Visual Studio.

Следующие шаги

Ваше приложение работает локально, и ваш следующий шаг — опубликовать его вместе с API.