Potrzebuję API

16 december 2021
Jakub Rojek Jakub Rojek
Oryginalne zdjęcie autorstwa ThisIsEngineering z Pexels (https://www.pexels.com/pl-pl/zdjecie/kobieta-pisze-na-tablicy-3861943/)
Categories: For clients, IT fundamentals

Żyjemy w świecie już nie programów komputerowych czy nawet samodzielnych aplikacji webowych, ale usług zwanych też serwisami. Są one wystawiane przez różne systemy, aby można było się z nimi komunikować i umożliwić korzystanie z danych (oczywiście, w uprawniony sposób) także w zewnętrznych aplikacjach. Na tym mechanizmie opiera się obecnie bardzo duża część oprogramowania, która integruje się ze sobą, pozwala na przesyłanie informacji z każdego zakątka Internetu, a tym samym - zwiększa swój zasięg i zyski właściciela.

To naturalne, że każdy z nas chce, aby jego system stał się szeroko używany i "integrowalny" z innymi aplikacjami. W tym miejscu niektórzy przypominają sobie, że słyszeli o czymś, co nazywa się API i pytają software house o to, czy też mogą mieć coś takiego w swoim portalu. Czasami wręcz, jako firma IT, słyszymy od klientów "chcemy API, ile czasu potrzebujecie?". Dlatego w tym tekście chcę wyjaśnić, czym właściwie takie API jest i dlaczego trzeba przemyśleć, do czego właściwie ma służyć.

Czym w ogóle jest API?

Na początku krótka notka encyklopedyczna - API to skrót powstały z terminu Application Programming Interface i oznacza interfejs do aplikacji (lub systemu komputerowego), ale nie graficzny, dla zwykłych użytkowników, tylko dla programistów. Służy bowiem zwykle do integracji zewnętrznego oprogramowania z naszym systemem lub dostępu do jego zasobów. API może przyjmować różne formy i tak naprawdę w pierwotnym znaczeniu było rozumiane jako udostępniona biblioteka, SDK lub zwyczajnie kod do włączenia w swoich programach. Natomiast obecnie najczęściej o API mówimy w kontekście usług sieciowych i przyjmiemy w dzisiejszym artykule wyłącznie taką interpretację.

API jest interfejsem tak samo przyjaznym programistom, jak interfejs graficzny (UI) jest wygodny dla użytkowników do standardowego "klikania". Teoretycznie istnieje możliwość integrowania się poprzez UI, ale jest to bardzo nierozsądne i korzysta się z tego tylko w ostateczności. Stąd obecność metod dostępowych, najlepiej jeszcze udokumentowanych, jest zbawienna przy integracjach.

Czym są usługi sieciowe i REST?

Powiedzmy sobie teraz, czym są te usługi sieciowe, webowe czy web serwisy (od angielskiego web services), o których już zdążyłem wspomnieć. Można powiedzieć, że są to specjalne adresy internetowe, tzw. endpointy (dosłownie "punkty końcowe", choć tutaj bardziej pasuje "punkty wejścia"), pod którymi udostępnione są dane lub operacje do wykonania na danych. W zależności od konkretnego adresu, jak i typu żądania możliwe są różne działania m.in. pobierające informacje czy wstawiające obiekty. Czasami służą też jako osobne funkcje do różnych, specjalizowanych czynności, których nie chcemy pisać samemu - tutaj macie przykład API usługi SendGrid do wysyłania maila.

Bardzo często przy okazji sieciowych API mówi się o API REST-owym i uważam, że warto to jawnie podkreślać podczas rozmów, aby mieć pewność, że obie strony tak samo rozumieją komunikację. REST to jeden z protokołów korzystania z usług sieciowych, oparty o zwykłe żądania HTTP, przez co jest bardzo prosty i możliwy do wykorzystania praktycznie w każdym przypadku. Tak naprawdę dominuje w świecie webowych API i dopiero od niedawna dość nieśmiało zaczyna się przebijać rozwiązanie zwane GraphQL. Niegdyś często stosowano protokół SOAP, ale z uwagi na jego poziom skomplikowania, lepiej skupić się na REST.

Po co może być mi potrzebne API?

Zdążyłem już wspomnieć, że API wykorzystuje się do integrowania różnych serwisów ze sobą, także po to, aby uatrakcyjnić swój system. Pokażmy sobie dwa przykłady.

1. Tworzymy serwis udostępniający kursy walut i chcemy, aby różni programiści mogli korzystać ze zbieranych przez nas wartości w swoich aplikacjach. W tym celu tworzymy API umożliwiające pobranie kursów (według różnych kryteriów) i udostępniamy je wraz z dokumentacją. Dzięki temu przysłużymy się społeczności, a dodatkowo można to "opakować" biznesowo w różnoraki sposób (np. nakładając limity dla użytkowników korzystających z darmowego konta, zachęcając do nabycia konta premium).

2. Tworzymy system pomagający planować wycieczki i jednym z wymagań jest pokazanie aktualnej pogody w miejscu wybranym przez użytkownika. Nie chcemy samodzielnie zbierać danych pogodowych, gdyż są różne API, które mogą nam w tym pomóc. Wybieramy dogodny dla nas serwis, zapoznajemy się z warunkami użytkowania (oraz ograniczeniami lub kosztami) i korzystamy z wystawionych usług.

Jak widać, bogactwo wynikające ze stosowania API jest związane głównie z łączeniem różnych serwisów ze sobą, ale to nie wszystko. Warto również zwrócić uwagę na to, że większość aplikacji webowych korzysta ze swojego API również do normalnego użytkowania - zazwyczaj oprogramowanie jest podzielone na frontend oraz backend i ten pierwszy komunikuje się z tym drugim właśnie za pośrednictwem API. W bardziej złożonych aplikacjach ułatwia to też podzielenie backendu na wiele serwisów (a nawet mikroserwisów), które wymieniają ze sobą dane właśnie między innymi za pomocą usług sieciowych.

Jak widać, tworzenie API ma sens z punktu widzenia architektury, a jego udostępnianie może także przynosić korzyści ze względów biznesowych. Można zatem powiedzieć, że warto od początku je planować i uwzględnić w założeniach aplikacji.

Co zrobić, gdy potrzebuję API?

I tutaj dochodzimy do pytania przywołanego we wstępie: "chcemy API, ile czasu potrzebujecie?". Otóż, musimy tutaj zdać sobie sprawę z kilku rzeczy.

Jeśli jest chociaż cień szansy, że taki interfejs dla programistów będzie w przyszłości potrzebny, warto powiedzieć o tym na jak najwcześniejszym etapie. Bardzo często bowiem opłaca się całą architekturę aplikacji oprzeć o API i w ten sposób przynajmniej ograniczyć pracochłonność późniejszych prac programistycznych. Jest to o tyle istotne, że takie usługi wymagają również odpowiedniego zabezpieczenia, opracowania mechanizmu uprawnień i jeżeli planujemy pisać kod z myślą o tym podsystemie, to należy to zrobić jak najwcześniej. Zresztą, obecne aplikacje webowe, poza tymi bardzo specyficznymi (np. do wewnętrznego zastosowania firm) praktycznie w większości wykorzystują przesyłanie danych w ten sposób.

Można również dodać API do aplikacji, która nie jest zbudowana w oparciu o taką komunikację - zależy to od technologii, ale zazwyczaj jest możliwe (co nie znaczy, że zawsze wygodne), a w ostateczności można pokusić się o drugi backend, którzy będzie wystawiany jako osobny interfejs. Poza kwestiami technicznymi, należy wziąć tutaj pod uwagę koszt wprowadzenia takiego rozwiązania do projektu od strony organizacyjnej.

Natomiast najważniejsze jest i tak zdefiniowanie, co dokładnie ma robić API. Żaden software house ani freelancer nie może nawet próbować wycenić stworzenia usług, jeśli nie pozna zakresu metod dostępowych, które system ma oferować poprzez interfejs dla programistów. Oczywiście, im bardziej szczegółowe są instrukcje, tym lepiej, natomiast przed rozpoczęciem kodowania niezbędne jest ustalenie kontekstu prac i możliwości, które API będzie oferowało. Poza jego funkcjonalnością, należy również uzgodnić inne kryteria - czy będzie to API publiczne, jakie dane będą potrzebne do autoryzacji, który protokół będzie obsługiwany, a także jakie ograniczenia przewidujemy dla użytkowników.

Podsumowanie

Systemy wystawiające API są zjawiskiem już tak powszechnym w sieci, że ten termin przewija się w rozmowach nawet pozainformatycznych i nic dziwnego, że każdy chce (lub potrzebuje), aby jego oprogramowanie taki interfejs udostępniało. Nie oznacza to jednak, że należy to robić bez planu działania - trzeba na początku przemyśleć, jaki mamy cel tworząc takie środowisko i do kogo będzie skierowane. Warto też jak najwcześniej uwzględnić API w swoich planach lub przynajmniej zasygnalizować firmie IT, czy będzie potrzebne w przyszłości.

Pozdrawiam i dziękuję - Jakub Rojek.

We write not only blog articles, but also applications and documentation for our clients. See who we have worked with so far.

About author

Jakub Rojek

Lead programmer and co-owner of Wilda Software, with many years of experience in software creation and development, but also in writing texts for various blogs. A trained analyst and IT systems architect. At the same time he is a graduate of Poznan University of Technology and occasionally teaches at this university. In his free time, he enjoys playing video games (mainly card games), reading books, watching american football and e-sport, discovering heavier music, and pointing out other people's language mistakes.

Jakub Rojek