Witajcie w kolejnym odcinku Microsoft Knowledge Nugget. Nazywam się Mirko Peters i będę Waszym gospodarzem. Tematem dzisiejszego odcinka jest coś, o czym prawie każdy słyszał, ale niewielu naprawdę rozumie API. Prawdopodobnie słyszeliście to określenie wielokrotnie. To jedno z tych technicznych słów, których ludzie używają, gdy chcą brzmieć, jakby wiedzieli, o czym mówią. Ale prawda jest taka, że API są w rzeczywistości proste. To po prostu sposób na komunikację między jednym a drugim programem. Twój telefon prosi serwer o dane. Serwer je odsyła. To właśnie wywołanie API. Wyobraź sobie teraz, że masz 20 API, 50 albo 100. Każde może używać innej autoryzacji, innych limitów szybkości, innej dokumentacji, jeśli w ogóle ją posiada. Nagle to, co zaczęło się jako prosta rozmowa między dwiema aplikacjami, zamienia się w kompletny chaos. Bez centralnego menedżera każdy zespół wyważa otwarte drzwi.

Jeden zespół buduje własny system autoryzacji, inny tworzy własne logowanie. Luki w zabezpieczeniach pojawiają się wszędzie. Programiści gubią się w tym, co robi dane API, a Ty nie masz jednolitego wglądu w to, co dzieje się w całym systemie. Azure API Management rozwiązuje ten problem. Daje Ci jedno centrum sterowania. Pomyśl o tym, jak owierzy kontroli lotów dla Twoich API. Pod koniec tego odcinka zrozumiesz, czym to faktycznie jest, dlaczego jest ważne i jak to wszystko do siebie pasuje. Chwyć kawę i przejdźmy do konkretów. Problem za dużo API, brak kontroli. Oto rzeczywistość nowoczesnego oprogramowania. 10 lat temu prawdopodobnie miałeś jedną dużą aplikację, monolit, jedną bazę danych, jedno API, proste. Dziś ta sama aplikacja może być podzielona na dziesiątki mikrousług. Każda usługa obsługuje jedną rzecz, konta użytkowników, płatności, zapasy, powiadomienia i każda wystawia własne API.

Nagle masz 10, 50, 100 różnych punktów wejścia do swojego systemu. Wyobraź sobie teraz, że jesteś programistą próbującym zbudować coś, co korzysta z tych API. Musisz znaleźć każde z nich i zrozumieć sposób autoryzacji dla każdego z osobna. Niektóre używają kluczy API, inne OAuth, a jeszcze inne nie używają niczego. Musisz ręcznie zarządzać limitami zapytań, inaczej ryzykujesz zablokowanie. Musisz zrozumieć format danych, którego oczekuje każde z nich. To wyczerpujące, a z perspektywy operacyjnej jest jeszcze gorzej. Bez centralnej bramy każdy zespół musi ręcznie dodawać zabezpieczenia i logowanie do swojej usługi. Niektóre zespoły robią to dobrze, inne zapominają o logowaniu błędów. Niektóre w ogóle nie sprawdzają poprawności danych wejściowych. Niespójne i podatne na błędy koszmar bezpieczeństwa, który tylko czeka, by się wydarzyć. Zgodność z przepisami staje się niemal niemożliwa. Musisz udowodnić, kto uzyskał dostęp do czego i kiedy.

Powodzenia w wyciąganiu ścieżek audytu z 20 różnych usług, z których każda ma własny format logowania. Musisz sprawdzić, ile wywołań API obsłużył twój system w zeszłym miesiącu. Łączysz wskaźniki z kilkunastu różnych pulpitów nawigacyjnych. Oto w czym rzecz. W miarę skalowania to nie tylko boli. To po prostu nie działa. Nie możesz dodawać więcej programistów, usług i klientów bez centralnego punktu kontroli. Pomyśl o tym jak o budynku. Wyobraź sobie, że każde pomieszczenie ma inny zamek. Nie ma recepcji ani spisu pomieszczeń. Goście błąkają się, próbując znaleźć właściwe drzwi, frustrują się i ostatecznie rezygnują. Totalny chaos. To problem, który ma rozwiązywać zarządzanie API. Czym jest Azure API Management? Wieża kontrolna. Czym dokładnie jest Azure API Management? Oto najprostsza definicja. To usługa zarządzana, która znajduje się między twoimi API zaplecza, a aplikacjami, stronami, urządzeniami i partnerami, którzy z nich korzystają.

Ale pamiętaj, to nie jest tylko proxy. Proxy jedynie przekazuje ruch i to wszystko. Azure API Management obejmuje pełny cykl życia twoich API. Publikuj, zabezpieczaj, monitoruj i ostatecznie wycofuj je z użycia. To kompletne centrum sterowania. Podzielmy to na trzy główne komponenty. Pierwszym jest brama, gateway. To główne wejście. Każde przychodzące żądanie z aplikacji lub strony trafia najpierw do bramy, nigdy bezpośrednio do zaplecza. Brama przetwarza żądanie, wymusza skonfigurowane zasady, zbiera metryki, a następnie przekazuje je do odpowiedniej usługi zaplecza. Pomyśl o tym jak o policjancie kierującym ruchem. Następny jest płaszczyzna zarządzania. To tutaj definiujesz wszystko. Swoje API, zasady, produkty, subskrypcje. Robisz to przez portal Azure, wiersz poleceń lub infrastrukturę jako kod, taką jak Bicep czy Terraform. To sterownia, w której konfigurujesz działanie całego systemu.

I na koniec portal programisty. To samoobsługowa strona, na której programiści, zarówno wewnętrzni, jak i zewnętrzni, mogą odkrywać Twoje API, czytać dokumentację, pobierać klucze subskrypcji, a nawet testować wywołania API bezpośrednio w przeglądarce. Koniec z przesyłaniem plików PDF-T i z powrotem. Oto pomocna analogia. Pomyśl o nowoczesnym lotnisku. Brama to pas startowy. Każdy samolot ląduje tam w pierwszej kolejności. Płaszczyzna zarządzania to wieża kontroli lotów. Kieruje ruchem, ustala zasady i monitoruje wszystko. A portal programisty to tablica informacyjna. Piloci sprawdzają ją przed lotem i znajdują wszystkie potrzebne informacje bez rozmawiania z nikim. Teraz przyjrzyjmy się bliżej bramie. To część, z którą komunikują się Twoje aplikacje i gdzie dzieje się prawdziwa magia. Brama, czyli frontowe drzwi Twojego API. Porozmawiajmy o bramie, ponieważ to właśnie ta część, z którą Twoje aplikacje faktycznie się komunikują.

Każde żądanie z aplikacji mobilnej, strony W czy urządzenia I od trafia najpierw do bramy, nigdy bezpośrednio do back-endu. O to właśnie chodzi. Brama znajduje się z przodu i działa jako pojedynczy punkt wejścia. Brama może stosować polityki przed przekazaniem żądania dalej. Polityki to reguły zapisane w XML lub JSON, takie jak limitowanie zapytań, filtrowanie IP, nadpisywanie nagłówków czy weryfikacja uwierzytelnienia. Wszystko to bez zmiany choćby jednej linii kodu back-endu. Oto konkretny przykład. Załóżmy, że masz darmowy i płatny poziom dostępu do swojego API. Dzięki polityce możesz ograniczyć darmowym użytkownikom liczbę żądań do 5 na minutę, a płatnym do 100. Twój back-end nawet nie dostrzega różnicy. Po prostu przetwarza żądania. Brama zajmuje się egzekwowaniem zasad. Brama obsługuje również buforowanie. Jeśli dane są żądane wielokrotnie, jak na przykład lista produktów, która rzadko się zmienia, brama może zapisać odpowiedź w cash i serwować ją bezpośrednio.

Nie trzeba w ogóle angażować back-endu, co oznacza szybsze odpowiedzi i mniejsze obciążenie serwerów. Może również przekształcać dane. Twój back-end może zwracać XML, ale aplikacja mobilna oczekuje JSON. Brama potrafi skonwertować je w locie. Twój back-end nie musi się zmieniać, aplikacja również nie. Brama zajmuje się tłumaczeniem formatu. Rejestruje także każde wywołanie, każde żądanie, każdą odpowiedź i każdy błąd. Otrzymujesz pełny dziennik audytu, kto, co wywołał, kiedy i co się wydarzyło. Samo to jest wystarczającym powodem, by stosować bramę dla zapewnienia zgodności z wymogami. Jeśli masz globalnych odbiorców, możesz wdrożyć bramę w wielu regionach. Ruch jest automatycznie kierowany do najbliższego punktu, co zapewnia niższe opóźnienia i lepsze doświadczenie. Jeszcze jedno, brama ukrywa prawdziwy adres URL twojego back-endu. Klienci widzą tylko adres bramy. Twoje serwery back-endowe pozostają ukryte przed internetem.

To ogromna korzyść dla bezpieczeństwa już na starcie. Polityki to silnik, który kontroluje wszystko. Co więc z tymi politykami, o których wspomniałem? To one sprawiają, że API M jest naprawdę potężny. Polityka modyfikuje zachowanie żądania lub odpowiedzi bez ingerencji w kod back-endu. Potraktuj to jak otoczkę wokół swojego API. Gdy ruch przepływa przez bramę, może ona automatycznie dodawać, usuwać lub zmieniać elementy. Polityki mogą działać w czterech punktach cyklu życia żądania. Inbound – przychodzące, zanim żądanie dotrze do twojego back-endu. Outbound – wychodzące, zanim odpowiedź dotrze do klienta. Back-end – tuż przed tym, jak żądanie trafi do twojej usługi. Oraz przy błędzie, gdy coś pójdzie nie tak. Typowe operacje przychodzące obejmują walidację tokenów JWT w celu sprawdzenia tożsamości, weryfikację kluczy API, nadpisywanie adresów URL oraz ograniczenie dostępu według adresu IP.

Wszystko to dzieje się, zanim twój back-end otrzyma choćby jedno żądanie. W przypadku ruchu wychodzącego możesz przekształcać treść odpowiedzi, wyszukiwać i zamieniać tekst, usuwać poufne pola, zmieniać formaty. Możesz buforować odpowiedzi, aby powtarzające się żądania nie obciążały twojego back-endu. Możesz nawet usuwać nagłówki, które ujawniają informacje wewnętrzne. Oto konkretny przykład. Załóżmy, że twoje API zwraca opisy produktów, w których wszędzie widnieje słowo niebieski. Chcesz zmienić branding i używać słowa żółty. Zamiast zmieniać kod back-endu, dodajesz jedną zasadę dla ruchu wychodzącego. Znajdź niebieski, zamień na żółty. I gotowe. Twój back-end pozostaje bez zmian. Zasady limitowania szybkości i kwot chronią twój back-end przed nadużyciami. Jeśli czyjaś aplikacja zacznie wysyłać 10 tysięcy zapytań na sekundę, zasada wkroczy do akcji i powie, zwolnij. Twój back-end pozostaje stabilny.

Potrzebujesz zaawansowanej logiki? Wewnątrz zasad możesz pisać własne wyrażenia w C-kratka. Są one kompilowane dla zapewnienia wydajności, więc nie ma narzutu w czasie wykonywania. Możesz sprawdzać rolę użytkowników, obliczać dynamiczne limity lub warunkowo przekształcać odpowiedzi na podstawie nagłówków. Kluczowy wniosek jest taki. Zasady pozwalają kontrolować zachowanie API bez dotykania kodu, który je obsługuje. Oznacza to szybsze zmiany, mniej wdrożeń i mniejsze ryzyko. Produkty i subskrypcje, czyli pakowanie API dla odbiorców. Twoje API są zdefiniowane, zasady ustalone, a bramka działa bez zarzutu. Ale jak dać różnym klientom dostęp do różnych zasobów? Właśnie do tego służą produkty i subskrypcje. W API i M grupujesz API w coś, co nazywamy produktem. Pomyśl o tym jak o pakiecie. Możesz mieć darmowy produkt zawierający tylko podstawowe API. Może to być dostęp tylko do odczytu, a potem produkt premium ze wszystkim, w tym operacjami zapisu i punktami końcowymi dla administratorów.

Deweloperzy nie subskrybują pojedynczych API, subskrybują produkt. Gdy dokonają subskrypcji, otrzymują klucz subskrypcyjny. Właściwie dwa klucze, dzięki czemu możesz zmieniać jeden bez przestojów. Ten klucz to ich przepustka do używania każdego API w ramach produktu. Ty kontrolujesz, jak działają subskrypcje. Produkty mogą wymagać zatwierdzenia. Możesz ręcznie akceptować każdego subskrybenta lub udostępnić je w trybie samoobsługowym. Każdy może się zapisać i uzyskać natychmiastowy dostęp. Możesz również dołączyć regulamin, który użytkownicy muszą zaakceptować przed subskrypcją. Jest to ważne, jeśli Twoje API obsługują poufne dane. W ten sposób zarabiasz na API. Darmowy produkt z niskim limitem 5 wywołań na minutę. Płatny produkt z wyższymi limitami lub większą liczbą punktów końcowych 100 wywołań na minutę oraz dostępem do funkcji premium. Twój backend nawet tego nie zauważy. Brama wymusza limity w oparciu o to, do którego produktu zapisał się użytkownik.

Oto prawdziwy przykład. Wyobraź sobie, że tworzysz aplikację konferencyjną. Tworzysz produkt dla uczestników z interfejsami API do harmonogramu sesji, biogramów, prelegentów i mapy obiektu. Następnie produkt dla sponsorów, który zawiera również interfejsy API do generowania leadów. Sponsorzy mogą skanować identyfikatory uczestników i uzyskiwać dane kontaktowe. Ten sam backend, różne produkty, różne poziomy dostępu. Te dwa klucze subskrypcji są zaprojektowane z myślą o rotacji. Jeśli klucz zostanie przejęty, generujesz nowy. Drugi klucz pozwala na przełączenie bez przerywania działania usługi. Generujesz nowy klucz, aktualizujesz aplikację, odwołujesz stary. Płynnie. Portal dla programistów. Samoobsługa dla konsumentów API. Skonfigurowałeś już swoje produkty API. Teraz programiści muszą je znaleźć. To zadanie portalu dla programistów. Portal dla programistów to witryna wbudowana w każdą instancję API i M.

Programiści używają go do przeglądania Twoich API, czytania dokumentacji i testowania punktów końcowych interaktywnie w przeglądarce. Bez konfiguracji i bez wysyłania e-maili w te i z powrotem. Jest jednak pewien szczegół, domyślnie jest nieopublikowany. Gdy tworzysz instancję API i M, portal już istnieje, ale nikt go nie widzi. Musisz go najpierw dostosować i opublikować. To zamierzone. Nie chcesz pokazywać światu niedokończonego portalu. Możesz dostosować kolory marki, logotypy, a nawet osadzić treści z Wordpressa jako blok obok dokumentacji API. Można go w pełni dostosować do wyglądu i stylu Twojej firmy. Prawdziwą wartością jest samoobsługa. Samoobsługa. Programiści rejestrują się, automatycznie otrzymują klucze subskrypcji i od razu zaczynają korzystać z API. Bez ręcznych e-maili, czekania na akceptację, czy zgłoszeń do wsparcia z pytaniami o klucz. Robią to samodzielnie, co znacznie zmniejsza obciążenie Twojego wsparcia.

Możesz również publikować dzienniki zmian i informacje o wydaniach. Gdy aktualizujesz API, programiści widzą to w portalu bez żadnych niespodzianek. Dostęp może być publiczny dla każdego z adresem URL lub ograniczony do użytkowników Twojego dzierżawy EntraID, aby tylko osoby z organizacji mogły go przeglądać. Obie opcje istnieją dla różnych przypadków użycia. Portal dla programistów sprawia, że zarządzanie API staje się prawdziwą platformą. Pomyśl o nim jak o witrynie sklepowej dla Twoich API. Bez niego programiści muszą przeszukiwać dokumenty i pytać innych. Dzięki niemu znajdują to, czego potrzebują i zaczynają budować. Bezpieczeństwo, uwierzytelnianie, autoryzacja i wpisy tajne. Cała ta moc jest bezużyteczna, jeśli bezpieczeństwo nie jest zapewnione. Porozmawiajmy więc o tym, jak APIM radzi sobie z tożsamością, dostępem i wpisami tajnymi. APIM obsługuje wiele metod uwierzytelniania. Najprostszą z nich są klucze subskrypcji, o których wspomnieliśmy wcześniej.

Jednak w systemach produkcyjnych potrzebujesz czegoś silniejszego jak OAuth 2.0, tokeny JWT, certyfikaty klientów czy filtrowanie IP. Nakładasz te warstwy w zależności od tego, jak wrażliwe jest Twoje API. W środowisku produkcyjnym najlepszą praktyką jest użycie OAuth 2.0 z EntraID. Oto jak to działa. Aplikacja kliencka pobiera token z EntraID i przesyła go wraz z żądaniem do API. APIM sprawdza poprawność tokenu, weryfikując podpis, wystawcę, odbiorcę i datę wygaśnięcia. Jeśli jest ważny, APIM przekazuje żądanie do Twojego backendu, dołączając token. Twój backend ufa mu, ponieważ APIM już go zweryfikował, więc nie musi robić tego ponownie. To o jedną rzecz mniej, którą musi obsługiwać każda usługa. Teraz porozmawiajmy o wpisach tajnych. Klucze API, parametry połączeń, certyfikaty nie chcesz, aby były wpisane na sztywno w plikach zasad lub kontroli źródła. APIM posiada funkcję o nazwie, nazwane wartości, named values.

Przechowujesz wpisy tajne centralnie w APIM i odwołujesz się do nich po nazwie w swoich zasadach. Rzeczywista wartość nigdy nie pojawia się w kodzie Twoich zasad. Co więcej, możesz połączyć nazwane wartości z usługą Azure Key Vault. Wpisy tajne pozostają zaszyfrowane w Key Vault, a APIM pobiera je w czasie wykonywania. Nikt, nawet Twój zespół DevOps, nie widzi rzeczywistej wartości wpisu tajnego. Gdy musisz zmienić klucz, aktualizujesz go w Key Vault, a APIM automatycznie pobiera tę zmianę. APIM obsługuje również tożsamości zarządzane, managed identities. Pozwala to APIM uwierzytelniać się w innych usługach Azure, takich jak Key Vault czy backendowe API, bez przechowywania żadnych poświadczeń. Azure zarządza tożsamością, więc Ty tylko nadajesz uprawnienia. Jeśli chodzi o izolację sieciową, możesz wdrożyć APIM wewnątrz sieci wirtualnej. To opcja dostępna w warstwie premium. Chodzi o to, że Twoje usługi backendowe nigdy nie muszą być bezpośrednio wystawione na działanie internetu.

APIM jest jedynym elementem, który widzi świat zewnętrzny. To warstwowe podejście buduje głęboką obronę. Uwierzytelnianie w bramie, wpisy tajne w skarbcu, izolacja sieciowa wokół Twoich backendów. Każda warstwa wzmacnia poprzednią. Warstwy cenowe, która z nich jest dla Ciebie odpowiednia? Ile to kosztuje? Przejdźmy przez poszczególne warstwy. Warstwa consumption, zużycie. Płacisz za wywołanie API bez stałych kosztów miesięcznych. Idealna dla małego ruchu lub nagłych skoków obciążenia, np. podczas prototypowania. Jeśli nie jesteś jeszcze pewien, czego potrzebujesz, zacznij tutaj. Warstwa developer zapewnia stały niski koszt miesięczny, około 50$. Pełen zestaw funkcji, ale bez gwarancji SLA. Idealna dla środowisk deweloperskich i testowych. Otrzymujesz wszystko, co ma wersja premium, ale nie możesz jej używać w produkcji. Warstwa basic to podstawowe rozwiązanie produkcyjne. Mniejsza przepustowość, brak wsparcia dla sieci wirtualnej, ale otrzymujesz prawdziwe SLA.

Dobra dla narzędzi wewnętrznych lub małych projektów, gdzie sieć prywatna nie jest krytyczna. Większość firm wybiera poziom standardowy. Obejmuje obsługę sieci wirtualnej, gwarancję SLA na poziomie 99,95% i dobrą przepustowość. Jeśli obsługujesz kluczowe dla biznesu interfejsy API, prawdopodobnie na tym poprzestaniesz. Poziom premium jest przeznaczony dla globalnych przedsiębiorstw wymagających maksymalnej niezawodności i sieci prywatnych. Wdrożenie wieloregionalne, własna brama SLA 99,99% i pełna integracja z siecią wirtualną. Ceny zaczynają się od około 2700 miesięcznie za jednostkę. Firma Microsoft wprowadziła również poziomy V2, Basic V2, Standard V2 oraz Premium V2. Upraszczają one cennik dzięki wliczonym limitom żądań i opłatom za milion przekroczeń. Zamiast śledzić wiele liczników, otrzymujesz jasną pulę żądań i płacisz za dodatkowe użycie w prostych transzach. Oto jak dokonać wyboru.

Zacznij od poziomu deweloperskiego do testów. Przejdź na standardowy w środowisku produkcyjnym. Wybierz premium, jeśli potrzebujesz globalnej skali lub sieci prywatnej. Pamiętaj, że zawsze możesz później zmienić poziom na inny. Zacznij od małych rzeczy i rozwijaj się w miarę zmiany potrzeb. Oto co omówiliśmy. Zarządzanie API porządkuje chaos wielu interfejsów, skupiając je w jednym centrum sterowania bramą, politykami, bezpieczeństwem i doświadczeniem programistów. Kluczowy wniosek jest taki, że to coś więcej niż tylko proxy. Pomyśl o tym jak o mózgu i układzie nerwowym swojego ekosystemu API. Bez tego każdy zespół buduje własne uwierzytelnianie, logowanie i limity szybkości. Kończy się to niespójnością, lukami w zabezpieczeniach i brakiem pełnego wglądu w sytuację. Dzięki temu zyskujesz spójność, bezpieczeństwo i skalowalność bez wyważania otwartych drzwi dla każdej usługi. Oto proste ćwiczenie.

Pomyśl o jednym API, które obecnie udostępniasz bezpośrednio. Może to być punkt końcowy funkcji lub usługa aplikacji. Jak umieszczenie zarządzania API przed nimi zmieniłoby stan bezpieczeństwa i możliwość monitorowania użycia? Samo przemyślenie tego ćwiczenia pokaże Ci jego wartość. Kolejny krok – zasubskrybuj kanał. W przyszłych odcinkach pokażemy, jak zaimportować API, zastosować pierwszą politykę i monitorować użycie w czasie rzeczywistym. Przejdziesz od teorii do praktyki. A jeśli uznałeś to za pomocne, udostępnij materiał komuś, kto tworzy aplikację. Oszczędzi im to miesięcy bólów głowy. Dziękuję za uwagę.