Wzorzec REST i trasy funkcji

  • 4 min

Masz już wspaniały interfejs API. Nie można zbyt wiele z nim zrobić, ale istnieje — a to więcej, niż mogą powiedzieć osoby, które nie zajmują się właśnie tworzeniem interfejsów API.

Migracja do interfejsów API RESTful

Masz punkty końcowe o nazwie CreateProduct, GetProducts, UpdateProduct i DeleteProduct. Punkty końcowe o nazwie w ten sposób stosują tradycyjny wzorzec nazewnictwa interfejsu API: Akcja/zasób.

Wzorzec nazewnictwa akcji/zasobu jest odpowiedni dla mniejszych interfejsów API. Pamiętaj jednak, że w tej symulacji firma Tailwind Traders to internetowy gigant. Interfejs API produktów może szybko stać się nieporęczny. Można na przykład sobie wyobrazić, że możesz mieć metodę o nazwie "GetProductByIdAndQuantityAndDate". Nie tylko te typy nazw metod są pełne, ale tworzą kod, który z nich korzysta, wyglądają zaśmiecony. Długie nazwy interfejsów API utrudniają też deweloperom zrozumienie sposobu korzystania z tych interfejsów API w projektach.

Musisz więc zadbać, aby Twój interfejs API był przejrzysty i intuicyjny. W tym celu użyjesz wzorca REST.

Trasy usługi Azure Functions i metody żądań HTTP

W usłudze Azure Functions domyślnie każda funkcja wyzwalacza HTTP odpowiada na żądania GET i POST. Ustawia również adres URL funkcji na nazwę tej funkcji poprzedzoną prefiksem "/api". Skonfigurujesz oba te elementy, aby przejść do wzorca RESTful przenoszenia.

Aplikacje dla przedsiębiorstw

Definicja HTTP interfejsu API w modelu programowania usługi Azure Functions w wersji 4 w tej przykładowej aplikacji znajduje się w ./api/src/index.ts temacie i jest zgodna ze wzorcem:

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

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

Funkcja obsługi jest oddzielona od definicji wyzwalacza HTTP. Pozwala to na dużą elastyczność w sposobie definiowania funkcji. Funkcję obsługi można zdefiniować w osobnym pliku i zaimportować do index.ts pliku. Ten format byłby łatwiejszy do obsługi lub generowania dla dokumentacji interfejsu OpenAPI lub struktury Swagger.

Mniejsze aplikacje

Mniejsze aplikacje mogą być lepiej obsługiwane przez zintegrowanie kodu procedury obsługi bezpośrednio z app wywołaniem przy użyciu metody aplikacji w celu określenia metody HTTP. Nadal można oddzielić funkcję obsługi lub zintegrować kod.

app.get Użyj metody , aby określić metodę HTTP i funkcję obsługi.

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

app.get('FunctionName', handlerFunction);

Innym alternatywnym formatem, idealnym rozwiązaniem dla aplikacji funkcji z jedną funkcją, jest zintegrowanie kodu programu obsługi bezpośrednio z app wywołaniem przy użyciu metody aplikacji w celu określenia metody HTTP. Na przykład:

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

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

Parametry tras

Możesz również użyć parametrów trasy, aby zdefiniować trasę, która akceptuje parametr. Na przykład poniższy kod definiuje trasę, która akceptuje name parametr:

route: "products"

Pełna definicja trasy to:

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

Określanie trasy zmienia wszystko po sekcji interfejsu API adresu URL. W poprzednim pliku konfiguracji trasa do funkcji GetProducts to teraz http://localhost:7071/api/products.

Wraz z trasą można przekazywać parametry. Parametry mają postać {parameterName}. Oznacza to, że aby przekazać parametr o nazwie id do punktu końcowego product , należy określić następującą trasę.

route: "products/{id}"

Mając tę nową wiedzę na temat architektury REST i sposobu jej implementacji w usłudze Azure Functions, możesz teraz utworzyć ten nieporęczny interfejs API produktów RESTful . To właśnie zrobisz w kolejnym ćwiczeniu.