REST и маршруты функций

Завершено

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

Миграция на API RESTful

У вас есть конечные точки с именами CreateProduct, GetProducts, UpdateProduct и DeleteProduct. Конечные точки, именованные таким образом, следуют традиционному шаблону именования API: действие или ресурс.

Для небольших API подходит шаблон именования Действие/ресурс. Учитывайте, что в этой модели Tailwind Traders — это большая компания интернет-продаж. В этом случае могут возникнуть проблемы с API продуктов. Представьте, например, что вам приходится иметь дело с методами вида GetProductByIdAndQuantityAndDate. Подобные названия методов не только избыточны, но и захламляют код, в котором они используются. Длинные имена API также усложняют их использование для разработчиков в своих проектах.

Необходимо сделать API ясным и понятным. Для этого вы будете использовать шаблон REST.

Маршруты Функций Azure и методы HTTP-запросов

В Функции Azure любая функция триггера HTTP по умолчанию отвечает на запросы GET и POST. Он также задает URL-адрес функции именем этой функции, префиксом "/api". Вы настроите оба этих параметра для перемещения шаблона RESTful.

Корпоративные приложения

Определение HTTP для API в модели программирования Функции Azure версии 4 в этом примере приложения найдено ./api/src/index.ts и соответствует шаблону:

const { app } = require('@azure/functions');

app.http('FunctionName',{
    methods: ['GET', 'POST'], 
    authLevel: 'anonymous', 
    route: 'routeName',
    handler: handlerFunction
});

Функция обработчика отделена от определения триггера HTTP. Это позволяет много гибких возможностей в определении функций. Вы можете определить функцию обработчика в отдельном файле и импортировать ее в index.ts файл. Этот формат проще поддерживать или создавать для документации OpenAPI или Swagger.

Небольшие приложения

Небольшие приложения могут лучше обслуживаться путем интеграции кода обработчика непосредственно в app вызов, используя метод приложения для указания метода HTTP. Вы по-прежнему можете разделить функцию обработчика или интегрировать код.

app.get Используйте метод, чтобы указать метод HTTP и функцию обработчика.

const { app } = require('@azure/functions');

app.get('FunctionName', handlerFunction);

Другой альтернативный формат, идеальный для приложений-функций с одной функцией, заключается в интеграции кода обработчика непосредственно в app вызов, используя метод приложения для указания метода HTTP. Например:

const { app } = require('@azure/functions');

app.get('helloWorld',{
    handler: (request: HttpRequest, context: InvocationContext) => {
        return {
            status: 200,
            body: "Hello World"
        }
    }
}

Параметры маршрута

Можно также использовать параметры маршрута для определения маршрута, который принимает параметр. Например, следующий код определяет маршрут, принимаюющий name параметр:

route: "products"

Полное определение маршрута:

app.http('GetProducts', {
    methods: ['GET', 'POST'],
    route: 'products',          // <- route: /api/products
    authLevel: 'anonymous',
    handler: GetProducts
});

При указании маршрута изменяется все, что следует после части api в URL-адресе. В предыдущем файле конфигурации маршрут к функции GetProducts теперь выглядит как http://localhost:7071/api/products.

Вы можете передать параметры вместе с маршрутом. Для параметров используется формат {parameterName}. Это означает, что для передачи параметра, вызываемого id конечной точке product , необходимо указать следующий маршрут.

route: "products/{id}"

Благодаря новым знаниям о REST и методах его реализации в Функциях Azure вы теперь можете сделать из неудобного API продуктов интерфейс RESTful. Это именно то, что вы сделаете в следующем упражнении.