Blog

Dlaczego Świat Nie Przetrwa Bez API?!

Dlaczego Świat Nie Przetrwa Bez API?!

Próbowałem policzyć, ile razy w swoich wpisach na blogu i w social mediach użyłem akronimu API. Wyszło mi coś pomiędzy dużo, a bardzo dużo. ;) Ciągle tylko API i API, ale… czym w ogóle to API jest? Po tytule możesz się domyślać, że chodzi o coś bardzo ważnego. Ale czy aż tak, by uznać, że zależą od niego losy świata? Czytaj dalej i przekonaj się sam.

Czym jest api?

Pozwól, że zacznę od teorii. Otóż API to skrót od Application Programming Interface. Jest to zbiór reguł, opisujących sposób, w jaki programy komunikują się między sobą. Z racji naszej specjalizacji (rozwijanie aplikacji internetowych), najczęściej mamy styczność z webowymi odmianami API.

Ale dość tej teorii. Lepiej zrozumiesz, gdy wytłumaczę Ci to na bardziej życiowym przykładzie. Wyobraź sobie, że jesteś w małym, osiedlowym sklepiku, w którym nie ma samoobsługi. Wszystkie produkty podaje Ci pani, która stoi za ladą.

Wszystko, co jest dostępne w sklepie to zasoby, których możesz zażądać. Kontynuując porównania, asortyment to nasz backend. Ty jako klient nie masz do niego bezpośredniego dostępu. O wszystko musisz prosić panią sprzedawczynię.

infografika sklep

To kwintesencja zasad i potrzeby działania API. Klient w sklepie to klient (widzisz, nawet nazwa jest taka sama;) ), który potrzebuje danych, aby wyświetlić je np. w przeglądarce. API, tak jak pani za ladą, ma dostęp do zasobów i przyjmuje od klientów zapytania, które realizuje. Tyle że pani sklepikarka wydaje towary, a API zwraca konkretny zasób. Odpowiednikiem asortymentu może być baza danych, pliki na serwerze etc.

Ktoś zaznajomiony z tematem może powiedzieć: chwila, przecież API to zbiór reguł komunikacji — gdzie to jest w przykładzie ze sklepem? Otóż nasz mózg pomija tę oczywistą kwestię, jaką jest używanie wspólnego języka. To jasne, że będzie Ci ciężko kupić herbatę za granicą, jeśli mówisz tylko po polsku. Oczywiście my ludzie możemy próbować się dogadać inaczej. Mamy do dyspozycji gesty, możemy pokazać lub narysować, o co nam chodzi.

Standardy określające zasady komunikacji

API ma trudniej, bo system nie może się domyślić, o co nam chodzi. Komunikacja musi być dokładnie zdefiniowana, żeby była udana. Właśnie po to powstały różne standardy określające zasady komunikacji. Są to:

  • REST API
  • GrapqQL
  • SOAP API

Ten ostatni jest już dużo rzadziej spotykany. Spotykam go głównie przy integracji z systemami państwowymi, np. GUS, który udostępnia dane o firmie na podstawie numeru NIP.

Zasady rest api

Ja natomiast najczęściej mam styczność z REST API i właśnie o nim chciałbym Ci teraz opowiedzieć nieco więcej. Został on zaprezentowany w 2000 roku przez doktora Roya Fieldinga. API zgodne ze specyfiką REST powinno cechować się następującymi elementami:

  • Jednolity interfejs — wszystkie żądania w celu pobrania danego zasobu powinny wyglądać tak samo, bez względu na to, skąd pochodzą. Innymi słowy, API nie powinno się zmieniać wraz z potrzebami poszczególnych klientów. Dostęp do konkretnego zasobu musi zawsze odbywać się w ten sam sposób i oferować konkretny zestaw danych.
  • Rozdzielenie klienta i serwera — systemy te powinny być od siebie niezależne, mimo iż tworzą jedną aplikację. Oczywiście aplikacja mobilna korzystająca z API w pewien sposób jest od niego zależna, ale jeden system nie może ingerować w drugi. API nie może dopisywać niczego do aplikacji klienckiej i na odwrót.
  • Bezstanowość — to jedna z prostszych zasad. Mówi, że każde żądanie jest niezależne i nie zawiera informacji o stanie poprzednim.
  • Zapis danych w buforze — jeśli system nie może obsłużyć wszystkich żądań na bieżąco, powinny się one zakolejkować i zostać obsłużone tak szybko, jak to będzie możliwe.
  • System warstwowy — między klientem a serwerem mogą istnieć różne warstwy komunikacji. Nie powinno to wpływać na ich działanie, a same warstwy powinny być transparentne dla obu systemów.
  • Kod na żądanie — jest to warunek opcjonalny. Po wykonaniu danego requestu serwer może zwrócić do klienta kod, który może zostać wykorzystany w aplikacji klienckiej.

Model dojrzałości Richardsona

Na pierwszy rzut oka może Ci się to wszystko wydać skomplikowane. Ciężko to ująć w prostszy sposób, a nie da się tego pominąć, bo to absolutne podstawy dobrze zaprojektowanego REST API. Dlatego zapisz sobie tę stronę, żeby mieć te informacje pod ręką w razie potrzeby. ;)

Gdy zastosujesz się do powyższych zasad, powinieneś otrzymać dobrze zaprojektowane API. Jeśli jednak "dobrze" to dla Ciebie za mało, koniecznie zapoznaj się z modelem dojrzałości Richardsona, definiującym 4 poziomy.

Większość firm zatrzymuje się na poziomie 2 (czyli przedostatnim — pamiętajmy, że w IT numerację zaczynamy od 0). Najwyższy poziom 3 wymaga dużo większego nakładu pracy, a nie oferuje wiele w zamian.

Podsumowanie

Myślę, że po przeczytaniu tego artykułu rozumiesz już, czym jest API. To właśnie API sprawia, że nasze urządzenia potrafią się ze sobą komunikować. To, że masz możliwość za pomocą smartfona sterować większością urządzeń w domu, jest możliwe właśnie dzięki określonemu sposobowi komunikacji.

Bardziej globalny przykład to istnienie wielu publicznych API, z których możemy czerpać dane i korzystać z nich w naszych aplikacjach. Żeby nie szukać daleko — to, że mogliśmy śledzić na bieżąco liczbę zakażeń od początku pandemii SARS-CoV-2, zawdzięczamy właśnie API.

Wyobrażasz sobie, co by się stało, gdyby ktoś nagle zabrał nam API? Śmiem twierdzić, że ludzkość czekałby totalny paraliż komunikacyjny. Tak, świat nie przetrwałby bez API.

A dla ciekawych świata API, poniżej link z dostępnymi API w Internecie. Znajdziesz tam zarówno opcje płatne, jak i darmowe :)

https://rapidapi.com/hub

Grzegorz Kielar

Grzegorz Kielar

Architekt możliwości

W Kielni Kodu dbam o to, żeby proponowane rozwiązania i technologie były dobrane do potrzeb i budżetu klienta. Poza zarządzaniem firmą i kontaktem z klientami odpowiadam za backend oprogramowania, kwestie związane z serwerami i usługami chmurowymi. Innymi słowy, robię wszystko to, czego nikt nie widzi i nie wie, dlaczego działa, ale działa :)

Prywatnie fotograf amator, mąż i właściciel psa Eliota.