Kompilowanie interfejsu API za pomocą usługi Azure Functions
Teraz nadszedł czas, aby utworzyć interfejs API dla aplikacji listy zakupów.
Azure Functions
Jedną z największych korzyści z używania usługi Azure Static Web Apps jest hostowanie razem aplikacji internetowej i interfejsu API skompilowanych za pomocą Azure Functions. Usługa Azure Static Web Apps globalnie dystrybuuje statyczne zasoby aplikacji internetowej i hostuje interfejs API w usłudze Azure Functions. Dzięki tej konfiguracji uzyskasz potrzebną dostępność i szybkość, dzięki globalnej dystrybucji zasobów aplikacji internetowej. Ważne jest również to, czego nie musisz robić.
Nie musisz konfigurować i obsługiwać pełnego serwera dla frontonu ani zaplecza. Ta funkcja jest słodkim miejscem dla usługi Azure Static Web Apps: łatwość publikowania aplikacji i interfejsu API przy minimalnej konfiguracji i konserwacji.
Usługa Azure Functions obsługuje punkty końcowe trasy, nie wymaga pełnego serwera zaplecza do konfigurowania ani konserwowania, a także zapewnia automatyczne skalowanie w poziomie i skalowanie na podstawie popytu. Te funkcje sprawiają, że usługa Azure Functions jest doskonałym partnerem interfejsu API dla aplikacji internetowej listy zakupów, która obsługuje zasoby statyczne.
Usługa Azure Static Web Apps generuje unikatowy adres URL witryny, który można znaleźć na karcie Przegląd w portalu. Interfejs API jest dostępny za pośrednictwem tego samego adresu URL, dołączając /api go do adresu URL.
Interfejs API listy zakupów
Twoja aplikacja z listą zakupów umożliwia różnym osobom pobieranie, dodawanie, aktualizowanie i usuwanie elementów z listy. Dlatego warto pamiętać, że interfejs API ma punkty końcowe spełniające te potrzeby.
Oto cztery punkty końcowe:
| Metody | Punkty końcowe trasy | Pełen punkt końcowy interfejsu API |
|---|---|---|
| GET | products |
api/products |
| POST | products |
api/products |
| ODŁÓŻ | products/:id |
api/products/:id |
| DELETE | products/:id |
api/products/:id |
Zwróć uwagę, że żądania HTTP GET kierują do interfejsu API/produktów. Prefiks api jest zarezerwowany dla punktów końcowych interfejsu API w aplikacji. Możesz zdefiniować inne trasy, aby dopasować je do potrzeb witryny, ale api zawsze wskazuje aplikację usługi Azure Functions.
Tworzenie interfejsu API dla aplikacji internetowej
Do tej pory używana była struktura frontonu. Wkrótce dodasz interfejs API i połączysz go z aplikacją frontonu. W repozytorium znajduje się projekt Api, który zawiera niekompletny projekt usługi Azure Functions i punkty końcowe HTTP dla żądań PUT, POST i DELETE dotyczących produktów. W interfejsie API brakuje funkcji HTTP GET. Ukończysz interfejs API projektu usługi Azure Functions i dodasz brakującą funkcję, a następnie połączysz interfejs API z aplikacją internetową frontonu.
Podgląd zmian w aplikacji internetowej
Przed wprowadzeniem zmian w aplikacji dobrą praktyką jest utworzenie nowej gałęzi dla zmian. Wprowadzasz kilka zmian po ukończeniu interfejsu API dla aplikacji, więc utworzysz gałąź dla tych zmian.
Po wprowadzeniu zmian należy je wyświetlić przed podjęciem decyzji o scaleniu zmian. Po utworzeniu żądania ściągnięcia z nowej gałęzi do gałęzi głównej akcja usługi GitHub kompiluje aplikację i interfejs API i wdraża je w adresie URL podglądu. Ten adres URL w wersji zapoznawczej umożliwia pozostawienie aplikacji internetowej uruchomionej za pomocą usługi Azure Static Web Apps, ale także wyświetlenie drugiego adresu URL z wynikami żądania ściągnięcia.
Konfigurowanie komunikacji między aplikacją internetową a interfejsem API
Po uruchomieniu interfejsu API lokalnie działa on domyślnie na porcie 7071. Aplikacja internetowa jest uruchamiana na innym porcie lokalnym. Gdy aplikacja internetowa próbuje wysłać żądanie HTTP z portu do portu 7071 interfejsu API, akcja jest nazywana udostępnianiem zasobów między źródłami (CORS). Przeglądarka uniemożliwia ukończenie żądania HTTP, chyba że serwer interfejsu API zezwala na kontynuowanie żądania.
Podczas publikowania w usłudze Azure Static Web Apps nie musisz martwić się o mechanizm CORS. Usługa Azure Static Web Apps automatycznie konfiguruje aplikację, tak aby mogła komunikować się z interfejsem API na platformie Azure przy użyciu zwrotnego serwera proxy. Zwrotny serwer proxy umożliwia korzystanie z aplikacji internetowej i interfejsu API, które pochodzą z tej samej domeny sieci Web. Dlatego mechanizm CORS trzeba skonfigurować tylko podczas uruchamiania lokalnego.
Następne kroki
Teraz możesz przystąpić do tworzenia interfejsu API i konfigurowania punktów końcowych HTTP dla aplikacji listy zakupów.