ARCHITEKTURA API PROJEKTOWANIE, UŻYWANIE I ROZWIJANIE SYSTEMÓW

Przedmowa

Wstęp

Wprowadzenie

CZĘŚĆ I. Opracowywanie, budowanie i testowanie API 33

1. Opracowywanie, budowanie i określanie API
Przykład opracowywania API uczestnika
Wprowadzenie do stylu REST
Oparte na przykładzie wprowadzenie do technologii REST i HTTP
Model dojrzałości Richardsona
Wprowadzenie do API zdalnego wywoływania procedur
Krótkie wprowadzenie do GraphQL
Struktura i standardy API REST
Kolekcje i stronicowanie
Filtrowanie kolekcji
Obsługa błędów
Wskazówki dotyczące dokumentu typu ADR – wybór standardu API
Określanie API REST za pomocą OpenAPI
Praktyczne zastosowanie specyfikacji OpenAPI
Generowanie kodu
Weryfikacja OpenAPI
Przykłady i imitacje
Wykrywanie zmian
Wersjonowanie API
Wersjonowanie semantyczne
Specyfikacja OpenAPI i wersjonowanie
Implementacja RPC za pomocą gRPC
Modelowanie zmian i wybór formatu API
Usługi z wysokim poziomem ruchu sieciowego
Ogromne ilości wymienianych danych
Korzyści związane z wydajnością działania HTTP/2
Stare formaty
Wskazówki dotyczące dokumentu typu ADR – modelowanie wymiany danych
Wiele specyfikacji
Czy istnieje złoty środek?
Wyzwania związane z połączeniem specyfikacji
Podsumowanie
2. Testowanie API
Użyty w tym rozdziale scenariusz systemu konferencyjnego
Strategie testowania
Kwadrant testów
Piramida testów
Wskazówki dotyczące dokumentu typu ADR – strategie testowania
Testowanie kontraktu
Dlaczego często preferowane jest testowanie kontraktu?
Jak jest implementowany kontrakt?
Wskazówki dotyczące dokumentu typu ADR – testowanie kontraktu
Testowanie komponentu API
Testowanie kontraktu kontra testowanie komponentu
Przykład użycia testowania komponentu do weryfikacji sposobu działania
Testowanie integracji API
Używanie szkieletów serwerów – kiedy i dlaczego?
Wskazówki dotyczące dokumentu typu ADR – testy integracji
Konteneryzowanie komponentów testowych – biblioteka Testcontainers
Przykład zastosowania biblioteki Testcontainers do weryfikacji integracji
Testy typu E2E
Automatyzacja weryfikacji E2E
Typy testów E2E
Wskazówki dotyczące dokumentu typu ADR – testowanie typu E2E
Podsumowanie

CZĘŚĆ II. API zarządzania ruchem sieciowym

3. Bramy API – zarządzanie przychodzącym ruchem sieciowym
Czy brama API to jedyne rozwiązanie?
Wskazówki dotyczące dokumentu typu ADR – proxy, mechanizm równoważenia obciążenia lub brama API
Przykład udostępnienia konsumentom usługi uczestnika
Czym jest brama API?
Jaką funkcjonalność może zaoferować brama API?
Gdzie zostaje wdrożona brama API?
Jak brama API integruje się z innymi technologiami w położeniu brzegowym?
Dlaczego warto używać bramy API?
Zmniejszenie poziomu powiązania przez użycie wzorca adaptera/fasady między frontendem a backendem
Uproszczenie sposobu użycia przez agregację i tłumaczenie usług backendu
Ochrona API przed nadużyciami dzięki wykorzystaniu mechanizmu wykrywania zagrożeń i ich łagodzeniu
Zrozumienie, w jaki sposób może być używane API (monitorowanie)
Zarządzanie API jako produktem poprzez zarządzanie cyklem życiowym API
Zarabianie na API dzięki użyciu mechanizmów zarządzania kontem, rozliczeniami i płatnościami
Nowoczesna historia bram API
Od lat dziewięćdziesiątych ubiegłego wieku – sprzętowe mechanizmy równoważenia obciążenia
Od lat dwutysięcznych – programowe mechanizmy równoważenia obciążenia
Pierwsza dekada XXI wieku – kontrolery dostarczania aplikacji
Druga dekada XXI wieku – pierwsza generacja bram API
Rok 2015 – druga generacja bram API
Taksonomia obecnych bram API
Tradycyjne bramy korporacyjne
Mikrousługi i mikrobramy
Bramy infrastruktury typu service mesh
Porównanie typów bram API
Przykład ewolucji systemu konferencyjnego z użyciem bramy API
Instalacja stosu Ambassador Edge Stack w Kubernetes
Konfigurowanie mapowania ze ścieżek dostępu adresów URL do usług backendu
Konfiguracja mapowania z użyciem routingu bazującego na hoście
Wdrażanie bramy API – poznanie niepowodzeń i radzenie sobie z nimi
Brama API jako pojedynczy punkt awarii
Wykrywanie i usuwanie problemów
Rozwiązywanie problemów i radzenie sobie z incydentami
Łagodzenie ryzyka
Najczęściej pojawiające się problemy podczas implementacji bramy API
Pętla zwrotna bramy API
Brama API jako korporacyjna magistrala usług
Bramy API aż do końca
Wybór bramy API
Określenie wymagań
Samodzielne opracowanie rozwiązania kontra zakup gotowego
Wskazówki dotyczące dokumentu typu ADR – wybór bramy API
Podsumowanie
4. Infrastruktura typu service mesh i zarządzanie ruchem sieciowym między usługami
Czy infrastruktura typu service mesh to jedyne rozwiązanie?
Wskazówki dotyczące dokumentu typu ADR – czy należy zastosować infrastrukturę typu service mesh?
Przykład wyodrębnienia funkcjonalności sesji do nowej usługi
Czym jest infrastruktura typu service mesh?
Jaką funkcjonalność dostarcza infrastruktura typu service mesh?
Gdzie jest wdrażana infrastruktura typu service mesh?
Jak infrastruktura typu service mesh integruje się z innymi topologiami sieci?
Dlaczego warto używać infrastruktury typu service mesh?
Pełna kontrola nad routingiem usługi, niezawodnością i zarządzaniem ruchem sieciowym
Niewidoczne monitorowanie
Wymuszenie bezpieczeństwa, np. szyfrowanie transmisji, uwierzytelnianie i autoryzacja
Obsługa komunikacji międzyfunkcyjnej w różnych językach programowania
Oddzielenie przychodzącego ruchu sieciowego od zarządzania ruchem sieciowym między usługami
Ewolucja infrastruktury typu service mesh
Wczesna historia i motywy
Wzorce implementacji
Czy niewymagająca proxy infrastruktura typu service mesh jest przyszłością?
Taksonomia infrastruktury typu service mesh
Przykład użycia infrastruktury typu service mesh na potrzeby związane z routingiem, monitorowaniem i zapewnieniem bezpieczeństwa
Routing za pomocą Istio
Monitorowanie ruchu sieciowego za pomocą Linkerd
Segmentacja sieci za pomocą narzędzia Consul
Wdrażanie infrastruktury typu service mesh – zrozumienie awarii i zarządzanie nimi
Infrastruktura typu service mesh jako pojedynczy punkt awarii
Najczęściej pojawiające się trudności podczas implementacji infrastruktury typu service mesh
Infrastruktura typu service mesh jako korporacyjna magistrala usług
Infrastruktura typu service mesh jako brama
Zbyt wiele warstw sieciowych
Wybór infrastruktury typu service mesh
Określenie wymagań
Samodzielne opracowanie rozwiązania kontra zakup gotowego
Lista rzeczy do sprawdzenia podczas wyboru infrastruktury typu service mesh
Podsumowanie

Część III. Funkcjonowanie API i jego zabezpieczanie

5. Wdrażanie i wydawanie API
Rozdzielenie wdrożenia i wydania
Przykład włączania funkcjonalności
Zarządzanie ruchem sieciowym
Przykład modelowania wydań w systemie konferencyjnym
Cykl życiowy API
Mapowanie strategii wydań na cykl życiowy
Wskazówki dotyczące dokumentu typu ADR – rozdzielenie operacji wdrożenia i wydania dzięki użyciu zarządzania ruchem sieciowym i techniki włączania funkcjonalności
Strategie wydań
Wydania kanarkowe
Odbicie lustrzane ruchu sieciowego
Niebieski-zielony
Przykład przeprowadzania wdrożenia za pomocą narzędzia Argo Rollouts
Monitorowanie pod kątem sukcesu i identyfikowanie niepowodzeń
Trzy filary monitorowania
Ważne wskaźniki dla API
Odczytywanie sygnałów
Decyzje związane z efektywnymi wydaniami oprogramowania
Buforowanie odpowiedzi
Propagowanie nagłówka na poziomie aplikacji
Rejestrowanie danych, aby ułatwić debugowanie
Rozważenie użycia sprawdzonej platformy
Wskazówki dotyczące dokumentu typu ADR – sprawdzone platformy
Podsumowanie
6. Bezpieczeństwo operacyjne – model zagrożeń dla API
Przykład zastosowania metody OWASP w API uczestnika
Ryzyko związane z niezabezpieczeniem zewnętrznego API
Modelowanie zagrożeń
Myśl jak atakujący
Jak odbywa się modelowanie zagrożeń?
Krok 1. – określ cele
Krok 2. – zbierz właściwe informacje
Krok 3. – rozłóż system na czynniki
Krok 4. – określ zagrożenia
Krok 5. – oceń ryzyko związane z zagrożeniami
Krok 6. – przeprowadź weryfikację
Podsumowanie
7. Uwierzytelnianie i autoryzacja API
Uwierzytelnianie
Uwierzytelnianie użytkownika końcowego z wykorzystaniem tokenów
Uwierzytelnianie między systemami
Dlaczego nie należy łączyć kluczy i użytkowników?
OAuth2
Rola serwera autoryzacji i interakcje API
JSON Web Token (JWT)
Terminologia i mechanizmy grantów OAuth2
Wskazówki dotyczące dokumentu typu ADR – czy należy rozważyć użycie OAuth2?
Grant kodu autoryzacji
Token odświeżania
Grant danych uwierzytelniających klienta
Dodatkowe granty OAuth2
Wskazówki dotyczące dokumentu typu ADR – wybór używanego grantu OAuth2
Zasięg OAuth2
Wymuszenie autoryzacji
Wprowadzenie do OIDC
SAML 2.0
Podsumowanie

CZĘŚĆ IV. Architektura ewolucyjna z użyciem API

8. Przeprojektowanie aplikacji do architektury bazującej na API
Dlaczego używać API do ewolucji systemu?
Tworzenie użytecznych abstrakcji – większa spójność
Definiowanie granic domeny – promowanie luźnego powiązania
Przykład pokazujący określenie granic domeny uczestnika
Opcje architekturalne stanu końcowego
Monolit
Architektura zorientowana na usługi
Mikrousługi
Funkcje
Zarządzanie procesem ewolucyjnym
Określenie celu
Używanie funkcji przystosowania
Podział systemu na moduły
Utworzenie API jako „szwów” dla rozszerzenia
Określanie zmiany punktów wzmocnienia w systemie
Ciągłe wdrażanie i weryfikacja
Wzorce architekturalne dla wykorzystujących API systemów ewoluujących
Wzorzec „strangler fig”
Wzorce fasady i adaptera
Tort API
Określanie potencjalnych możliwości i trudnych miejsc
Problemy związane z uaktualnieniami i obsługą techniczną
Problemy związane z wydajnością działania
Przerwanie zależności – wysoce powiązane API
Podsumowanie
9. Używanie infrastruktury API do ewolucji w kierunku platform chmury
Przykład przeniesienia usługi uczestnika do chmury
Wybór strategii migracji do chmury
Retain lub Revisit
Rehost
Replatform
Repurchase
Refactor/Rearchitect
Retire
Przykład zmiany platformy dla usługi uczestnika i przeniesienie jej do chmury
Rola zarządzania API
Ruch sieciowy typu północ – południe kontra ruch sieciowy typu wschód – zachód – zanikanie granic zarządzania ruchem sieciowym
Rozpoczęcie od położenia brzegowego, a następnie przejście do wnętrza sieci
Przekraczanie granic – routing między sieciami
Od architektury bazującej na strefach do sieci o zerowym zaufaniu
Architektura bazująca na strefach
Nie ufaj nikomu i sprawdzaj
Rola infrastruktury typu service mesh w architekturze bazującej na zerowym zaufaniu
Podsumowanie
10. Podsumowanie
Spojrzenie wstecz na naszą podróż
API, prawo Conwaya i Twoja organizacja
Poznajemy rodzaje decyzji
Wybieganie w przyszłość
Komunikacja asynchroniczna
HTTP/3
Platforma typu service mesh
Co dalej? Jak nadal poznawać architekturę API?
Nieustanne doskonalenie podstaw
Śledzenie nowości w branży
Radary, kwadranty i raporty dotyczące trendów
Poznawanie najnowszych praktyk i przykładów
Uczenie się przez działanie
Uczenie się przez nauczanie