Podejście API-first: na czym polega i co daje

Podejście API-first w budowie aplikacji i produktów zyskuje coraz większą popularność. Zwolennicy wskazują na jego przewagi biznesowe oraz elastyczność w procesie tworzenia oprogramowania. Warto więc dokładniej przyjrzeć się temu, czym właściwie jest API-first i dlaczego jego stosowanie staje się coraz powszechniejsze.

 

Co oznacza „API” w API-first?

Termin API stał się dziś jednym z modnych pojęć w świecie biznesu i technologii, często pojawiającym się w kontekście tzw. API economy. Podobnie coraz częściej można usłyszeć o koncepcji API-first.

Jednak wiele osób, które spotykają się z tymi terminami, nie ma pełnej świadomości, co właściwie oznaczają. Aby zrozumieć zalety podejścia API-first, trzeba najpierw wyjaśnić, czym jest samo API, a dopiero potem omówić strategię, która się na nim opiera.

API to skrót od application programming interface, czyli interfejs programowania aplikacji. w najprostszych słowach to pośrednik, który pozwala dwóm odrębnym aplikacjom komunikować się ze sobą, przesyłając dane w obie strony. Dzięki temu różne aplikacje mogą udostępniać swoje funkcje użytkownikowi.

API można porównać do tłumacza, który przekazuje wiadomości między dwiema osobami nieznającymi wspólnego języka. Obecność takiego tłumacza umożliwia komunikację, która w innym wypadku byłaby niemożliwa.

Punkty końcowe API (API endpoints) określają, kiedy i w jakim miejscu dwa urządzenia mogą się ze sobą „porozumieć”, skutecznie łącząc dwa systemy, niezależnie od ich systemów operacyjnych czy używanych języków programowania.

Jednym z najbardziej rozpoznawalnych przykładów API w codziennym użyciu jest logowanie przez media społecznościowe. Kiedy użytkownik chce zalogować się do swojego konta, może potwierdzić swoją tożsamość za pomocą zewnętrznego dostawcy, takiego jak Apple, Facebook czy Google. w tym momencie API przekazuje odpowiednie dane do danej platformy, umożliwiając autoryzację użytkownika.

Cały proces sprowadza się do jednego kliknięcia lub skanu odcisku palca zamiast ręcznego wpisywania danych w kilku polach formularza.

Ta wymiana żądań i odpowiedzi w ramach API umożliwia komunikację między aplikacjami, a tym samym pozwala firmom oferować użytkownikowi usługi bez konieczności każdorazowego tworzenia wszystkich funkcjonalności od podstaw.

Dziś wykorzystanie API jest wszechobecne. Gdy na stronie firmy widać mapę Google z jej lokalizacją, to właśnie dlatego, że osadzono tam API umożliwiające przesyłanie danych z Google Maps. Jeśli na pulpicie komputera wyświetlane są aktualne dane pogodowe, dzieje się tak dlatego, że system operacyjny komunikuje się z aplikacją pogodową za pomocą API, prezentując użytkownikowi potrzebne informacje w wygodnej formie.

 

Na czym polega podejście API-first?

 

Pierwszoplanowi obywatele

Jak sugeruje sama nazwa, podejście API-first to proces tworzenia oprogramowania, w którym API jest traktowane jako centralny i najważniejszy element aplikacji. Prace projektowe zaczynają się właśnie od API zanim powstanie jakakolwiek inna część systemu. z tego powodu mówi się, że API są w tym modelu „obywatelami pierwszej kategorii” (first class citizens).

To zupełnie inne podejście niż w tradycyjnym modelu code-first, gdzie najpierw tworzy się aplikację, a dopiero na końcu dodaje do niej API. w takim przypadku możliwości aplikacji w zakresie integracji z innymi systemami są ograniczone, co zmniejsza jej zasięg, funkcjonalność i żywotność.

 

API jako narzędzie komunikacji

W podejściu API-first to właśnie interfejs API stanowi fundament projektu. Jest pierwszym elementem, który powstaje, a jego struktura i funkcjonalność wynikają z celów biznesowych i potrzeb danej aplikacji. Celem jest stworzenie rozwiązania, które będzie mogło komunikować się z jak największą liczbą innych aplikacji i usług oraz pozostanie kompatybilne przez długi czas.

Ta długoterminowa zdolność do komunikacji z innymi komponentami to kluczowa zaleta podejścia API-first. Kiedy pojawia się potrzeba wprowadzenia nowych funkcji, programiści mogą je tworzyć w dowolnym momencie, dopasowując je do już istniejącego, centralnego API bez konieczności modyfikowania podstawowej architektury.

 

Kontrakty i dokumentacja

Takie podejście wymaga istnienia kontraktu API, jasno zdefiniowanego i zrozumiałego dla innych zespołów deweloperskich. Kontrakt ten stanowi szczegółową dokumentację, która opisuje sposób działania API, stosowane procedury oraz język programowania. Dzięki temu kolejne zespoły mogą rozwijać aplikację w przyszłości, opierając się na wspólnym, spójnym standardzie.

Dobra dokumentacja, wsparta odpowiednim przewodnikiem stylu API (API style guide), jest niezbędna, by zespoły pracujące w różnych strefach czasowych mogły skutecznie współpracować zarówno synchronicznie, jak i niezależnie od siebie.

Kiedy dokumentacja osiągnie wystarczający poziom precyzji, aplikację można budować i modyfikować wokół API bez konieczności pisania kodu od nowa. Właśnie w tym tkwi jedna z największych zalet podejścia API-first — znaczące ograniczenie potrzeby kosztownych i czasochłonnych przeróbek.

 

Konsultacje z klientem i informacja zwrotna

Integralną częścią procesu API-first są dogłębne konsultacje z klientem pozwalające zrozumieć jego potrzeby biznesowe i określić, jakie funkcje i usługi powinny znaleźć się w aplikacji.

Na tej podstawie można opracować kontrakt API i stworzyć makiety API (mock APIs) jeszcze zanim rozpocznie się właściwe kodowanie aplikacji. Taki etap przygotowawczy pozwala mieć pewność, że API, jako centrum całego systemu, spełni oczekiwania projektu. Dodatkowo wczesne testy i obsługa błędów już na poziomie projektowania API pozwalają uniknąć wielu błędów konstrukcyjnych.

API stworzone w duchu API-first jest więc rozwiązaniem unikalnym: dopasowanym do konkretnego klienta i łatwym do ponownego wykorzystania w jego przyszłych aplikacjach czy projektach.

 

Monolit czy mikroserwisy?

Architektura monolityczna to zazwyczaj przykład wspomnianego wcześniej podejścia code-first, odmiennego od API-first. w tym modelu rozwój oprogramowania koncentruje się na funkcjach, danych i zdarzeniach uruchamianych w ramach jednego spójnego modułu, a nie szeregu niezależnych jednostek serwisowych zwanych microservices.

Dyskusja o zaletach i wadach monolitu versus mikroserwisów trwa od lat. Skoro jednak strategia API-first zakłada, że funkcje i usługi można dodawać później w razie potrzeby, to naturalnie sprzyja ona infrastrukturze mikroserwisowej.

Dzieje się tak, ponieważ podstawowa logika podejścia API-first odzwierciedla konstrukcję mikroserwisów: odrębnych, wyspecjalizowanych komponentów odpowiedzialnych za własne funkcje. Takimi odrębnymi jednostkami mogą być również wiele API, które wspólnie powiększają aplikację i czynią ją bardziej elastyczną.

To przeciwieństwo monolitu, gdzie wszystko zawiera się i jest zakodowane w jednym systemie, co może powodować problemy operacyjne nawet przy drobnych zmianach. w projekcie opartym na API-first ten problem nie występuje.

Architektura monolityczna wymaga też jednego zespołu deweloperskiego, wystarczająco dobrze znającego monolit, by móc z nim skutecznie pracować.

Jak już wskazano, architektura API-first pozwala różnym zespołom pracować nad różnymi częściami projektu równolegle w trakcie developmentu. Dzieje się tak dlatego, że zespoły pracują nad odrębnymi mikroserwisami, a spoiwem jest pierwotny projekt API powstały na etapie wstępnych, szczegółowych konsultacji z klientem.

 

Podsumowując, podejście API-first:

• Pozwala klientowi precyzyjnie określić cele i konkretne potrzeby biznesowe.
• Przekłada cele biznesowe na kontrakt API, utrzymywany dzięki klarownej i powtarzalnej dokumentacji, co umożliwia kompetentnym deweloperom rozwijanie pojedynczych funkcji i komponentów w dowolnym momencie.
• Zapewnia przetrwanie i utrzymanie aplikacji dzięki natywnemu API (native API) , które staje się unikalnym zasobem firmy.

 

Zalety API-first

Mając powyższe podsumowanie, można przyjrzeć się konkretnym korzyściom:

• Lepsze doświadczenie deweloperskie (developer experience, w skrócie DevEX): zespoły mogą pracować nad różnymi częściami aplikacji w izolacji, niezależnie testować błędy kluczowych funkcji i nie ingerować w pracę innych zespołów ani innych API.
• Spójność projektu: projekt API trzyma się wytycznych zawartych w dokumentacji i jasnym API style guide. Ułatwia to integrację API i innych komponentów bez naruszania spójności całości.
• Zgodność z oczekiwaniami biznesowymi: projekt API powstaje po gruntownych konsultacjach z klientem zanim wydarzy się cokolwiek innego. Taki tryb prac ogranicza negatywny feedback w trakcie trwania projektu.
• Wczesne testy i szybkie wykrywanie błędów: etap wczesnego projektowania API umożliwia wczesne testowanie i troubleshooting. Ukończenie projektu API na starcie pozwala szybko sprawdzić, jak różne elementy współdziałają, co gwarantuje szybką integrację przy minimalnej liczbie problemów.
• Wielokrotne wykorzystanie: projektowanie w duchu API-first umożliwia tworzenie wielu aplikacji nawet przy wykorzystaniu jednego API. Przy dokumentacji opartej na jasnym przewodniku stylu, silne API governance pozwala budować zaawansowane aplikacje o wielu funkcjach.
• Szybszy time-to-market: oszczędność czasu na powyższych etapach przekłada się na szybszą implementację poszczególnych elementów i szybsze wprowadzenie produktu na rynek.
• Gotowość webowa i mobilna: REST API zapewniają natychmiastową użyteczność komponentów w sieci na różnych platformach i systemach operacyjnych, w tym na urządzeniach mobilnych.

 

Korzyści biznesowe z podejścia API-first

Wiele zalet tworzenia platform w duchu API-first przekłada się bezpośrednio na korzyści dla klienta. Wynikają one ze specyficznych cech tego podejścia do budowy interfejsów API dla aplikacji.

• Spójne i wielokrotnego użytku API sprawiają, że projekt może mieć trwały, mierzalny efekt i stanowić inwestycję w przyszłość firmy. Ponieważ podejście API-first zakłada długowieczność projektu, jego centralnym założeniem jest elastyczność oraz możliwość dodawania nowych funkcji w dowolnym momencie cyklu życia aplikacji.
• Niższe koszty rozwoju. Funkcje aplikacji nie muszą być projektowane kolejno ani w sposób, który uzależnia je od siebie, jak w architekturze monolitycznej. Zespoły mogą więc pracować w swoim tempie, co przekłada się na znaczne oszczędności czasu i kosztów developmentu.
• Ponowne wykorzystanie komponentów. Wielokrotnego użytku API umożliwia budowanie wielu aplikacji i projektów w oparciu o te same komponenty, stworzone wspólnie przez zespoły deweloperskie i klienta. Firma zyskuje w ten sposób podstawowe narzędzie, które może wykorzystywać w kolejnych przedsięwzięciach biznesowych, co również oznacza dalsze oszczędności.
• Skalowalność i łatwiejsze utrzymanie. Ponieważ API stanowi rdzeń aplikacji, jest fundamentem, wokół którego organizowane są wszystkie procesy. Takie podejście gwarantuje wyjątkową skalowalność. Nowe funkcje można wprowadzać po prostu jako mikro-frontendy (micro frontends). Dodatkowo ułatwia to rozwiązywanie problemów, a wysoka jakość dokumentacji sprawia, że każdy zespół może w dowolnym momencie dołączyć do projektu i sprawnie nad nim pracować.

 

Podsumowanie

Jak wynika z powyższego, podobnie jak architektura mikroserwisowa, podejście API-first jest niezwykle elastyczne i responsywne wobec zmieniających się potrzeb i warunków biznesowych.

Nowe funkcjonalności czy modyfikacje projektu można po prostu „podpiąć” pod istniejące rdzeniowe API, zamiast wprowadzać daleko idące zmiany w jednym, spójnym monolicie, co w tradycyjnych systemach często wiąże się z kosztownymi konsekwencjami.

Dodatkowo wykorzystanie mock APIs już na etapie wczesnego planowania i projektowania z klientem pozwala na uzyskanie bogatszej informacji zwrotnej, wcześniejsze testy oraz ocenę koncepcji. Dla biznesu oznacza to przyspieszenie procesu wdrożenia produktu na rynek i większą kontrolę nad końcowym rezultatem.