Jak działają strony i aplikacje
1 godz. 24 min · Biznes i Automatyzacje
Grzegorz RógIdea ArchitectCzy ja naprawdę muszę to wiedzieć? Czy to ważne, co dzieje się po wpisaniu adresu w przeglądarce, jak on jest skonstruowany i co zawiera? Wbrew pozorom - bardzo! Wiedza o tym, jak przeglądarka interpretuje to, co do niej wpisujemy przyda Ci się w wielu aspektach, nie tylko w programowaniu. Dzięki temu zrozumiesz jak serwer wymienia informacje z przeglądarką, jak działają UTMy w marketingowych kampaniach, czy wyszukiwarka, z której możesz przechwycić informacje w Analytics. Poznasz też kilka pojęć związanych z konsolą i parę przydatnych komend.
Porozmawiamy o tym, jak komunikować się efektywnie z serwerem, jakie są typy zapytań i jak możemy je egzekwować. Przy okazji poznasz aplikację Postman, z której będziesz mógł wygodnie wysyłać zapytania do serwera i przeglądać odpowiedzi. Jest to program, bez którego współczesny web development byłby bardzo utrudniony a komunikacja z back-endem dużo trudniejsza w implementacji.
Jak są zapisywane dane sesji, jakie dane przechowuje przeglądarka i po co? Odpowiedzi na te pytania pomogą Ci uniknąć frustracji w przypadku, gdy dane zostaną niepotrzebnie scache'owane ale także dowiedzieć się, jak zoptymalizować zasoby na stronie, które mogą być serwowane szybciej dla użytkownika. Zobaczysz, jak wygląda proces tworzenia ciasteczek, poznasz pojęcia jak Session Storage i Local Storage, to wszystko na kilku praktycznych przykładach.
W kursie przyjrzymy się szczegółowo działaniu API, poznasz podstawowe koncepcje, które stoją za najbardziej popularną metodą komunikacji z back-endem w nowoczesnych aplikacjach. Pomówimy o formacie JSON, będziemy też wysyłać zapytania do API takich aplikacji jak Twitter czy Google. W ten sposób dowiesz się, jak działają mechanizmy, które pozwolą Ci zintegrować się z najpopularniejszymi narzędziami w sieci!
Z kursem powinien zapoznać się z nim każdy, kto planuje tworzyć strony internetowe i chce rozwijać swoją karierę w ścieżkach webdevelopmentu. Jest to podstawowy materiał, który co prawda nie wchodzi w szczegóły jak sama konstrukcja API czy tworznie Rest API, ale jest uniwersalnym fundamentem wiedzy do różnych ścieżek. Przyda się też twórcom i właścicielom internetowych projektów, którym pozwoli lepiej zrozumieć mechanizmy działające pod maską webowych stron i aplikacji po to, aby je rozwijać czy korzystać z automatyzacji.
Cześć, witaj w kolejnej lekcji.
Wiesz już naprawdę dużo o protokole HTTP,
więc możemy przejść do API, czyli Application Programming Interface, czyli
do czegoś na czym działa w zasadzie cały internet.
Kiedyś, kiedyś dawno temu wystarczała taka architektura, gdzie mieliśmy jeden serwer,
jednego klienta, czyli mnie z przeglądarką,
ja wpisywałem sobie adres np.
google.com to leciało do serwera i tam
działa się cała magia i to do mnie wracało.
Problem niestety polega na tym, że w
obecnych czasach mamy masę urządzeń, mamy masę takich
możliwości korzystania z różnych aplikacji, które dają nam dostęp do tych
samych zasobów, do tych samych danych, a zarazem do tego samego serwera.
Weź np. aplikację banku.
Ta aplikacja banku oczywiście jest na
jednym centralnym serwerze, który potrafi wyliczyć Twoje saldo na koncie.
No ale teraz Ty możesz łączyć się do niej albo z klienta,
którym jest przeglądarka na komputerze, ale możesz też połączyć się z aplikacji
mobilnej, ale prawdopodobnie do Twojego konta
może też połączyć się jakaś osoba z
administracji banku, być może jakąś inną aplikacją, ich CRM itd itd.
W związku z tym wszystkie te aplikacje komunikują się w pewien sposób z
serwerem i dzieje się to właśnie przez API.
API nie jest niczym innym jak tym naszym
protokołem HTTP, tylko w pewien sposób ustrukturyzowanym. Więc bazuje to na
protokole HTTP i pozwala mieć jedną logikę biznesową, czyli jeden serwer, który
wylicza te wszystkie dane na kontach i dodatkowo wszyscy mogą się z nim łączyć
w pewien ustrukturyzowany sposób pytając o różne dane.
Akurat banki oczywiście tego nie robią, żeby udostępniać dane losowym osobom, ale
generalnie jeśli wymyślili byśmy sobie, że my zrobimy aplikację jakiegoś sprytnego
portfela, który zarządzał by naszymi wydatkami, no to musielibyśmy się np.
połączyć z API banku po to,
żebyśmy mogli odczytać całą historię wydatków danego klienta.
Jeżeli bank udostępniał by nam takie API
moglibyśmy z pomocą odpowiednich metod GET, POST itd.
np.
z pomocą GET odebrać te dane i zbudować sobie na nich naszą własną aplikację.
Czyli w tym momencie
w zasadzie jeśli jakiś serwis nie ma API to praktycznie nie istnieje.
Bardzo często będziemy łączyć się z różnymi serwisami i tak naprawdę można
teraz powiedzieć, że samemu nie musimy tworzyć dużej ilości danych.
Możemy po prostu podpiąć się pod
odpowiednie dane i stworzyć sobie ich wersję.
Czyli np.
jeżeli chcielibyśmy korzystać z danych pogodowych nie ma problemu.
Jest masa API, które wystawiają nam
informacje o aktualnej pogodzie w różnych miejscach na świecie.
Następnie mamy API, które powiedzmy Food & Drink.
Zobaczmy i zobaczmy np.
PUNK API i jego dokumentację. Zobacz, że
mamy taki główny tzw.
endpoint i to jest pierwsze ważne słowo,
na które skoro już na nie trafiamy to je wytłumaczmy.
Endpoint to jest generalnie tzw.
końcówka, czyli końcówka w sumie adresu URL, do której będziemy się odwoływać.
Endpoint jest takim technicznym
sformułowaniem w kontekście tego, jak API są tworzone, ponieważ jeśli np.
mielibyśmy klientów, to mielibyśmy przykładowo endpoint clients.
Gdy mielibyśmy ich zamówienia to mielibyśmy endpoint clients/orders np.
coś takiego. Więc to jest ten pierwszy endpoint, czyli
po prostu taki adres URL i jego końcówka, pod którą będziemy się łączyć.
Następnie mamy
poszczególne polecenia curl, czyli poszczególne, te konkretne endpointy,
do których możemy się łączyć po to, żeby odebrać sobie różne rzeczy, np.
weźmy piwo, czyli mamy tutaj adres, który zwróci nam informacje o różnych piwach
prawdopodobnie. Jeśli byśmy go otworzyli w
ten sposób w przeglądarce i mamy zainstalowany ten dodatek, który nam
zwróconego przez serwer JSON ładnie sparsuje, ładnie wyświetli, no to zobacz, że
generalnie w odpowiedzi na takie zapytanie o to piwo jeszcze raz sobie je wykonajmy.
Przejdźmy do Network.
Będziemy mieli właśnie dokładnie tą odpowiedź Response
tyle, że w przeglądarce
tutaj nie wygląda to zbyt ładnie, a jako, że mam ten dodatek to widzimy, że mamy
różne nazwy piw, kiedy zostały wyprodukowane, ich opisy, a nawet obrazki.
Jeżeli klikniemy sobie w taki obrazek,
będziemy mogli zobaczyć obrazek danego konkretnego piwa.
Więc na tym możemy już zacząć budować sobie jakąś aplikację.
Korzystając z tych danych będziemy mogli np.
wyświetlać je u nas.
Naturalnie musielibyśmy w pewien sposób je przefiltrować.
Czyli jeśli chodzi o np. piwa, chcielibyśmy
dostać powiedzmy jakieś konkretne na jakieś właściwe zapytanie i zobacz, że
to się akurat w tym API odbywa przez te parametry, o których Ci wspomniałem.
Czyli mamy tutaj listę parametrów, które będą nam zwracać odpowiednie rzeczy.
Możemy też dostać jakieś pojedyncze piwo, które jest pod jakimś indeksem.
Czyli jeśli chcielibyśmy wyświetlić tylko takie konkretne piwo, możemy to skopiować,
ale tak jak powiedziałem, jeżeli chcemy zawęzić wyniki wyszukiwania, to część API
jest przygotowana w ten sposób, że możemy to zrobić z pomocą parametru.
I teraz np. możemy wyświetlić sobie tylko piwa malt
albo tylko piwa hops, albo poszukać piwa po jakiejś konkretnej nazwie.
Tutaj mamy też przykład konstruowania takiego parametru
i możemy sobie to skopiować i to nam wyświetli wszystkie piwa,
które zostały uwarzone przed 2012 rokiem.
Jeszcze jakiś dodatkowy tu jest parametr, który możemy sobie go wyszukać w
dokumentacji i zobaczyć, co on robi abv_ gt.
Zwraca nam wszystkie piwa abv większe niż ten jakiś numer.
Dobra, nie wiem co to do końca jest, ale zawsze w API się to znajdzie
i zobacz, że taki wynik tutaj otrzymujemy
i jest tych wyników już zdecydowanie mniej, ale za to są te, które są przed 2012.
Jak byśmy tutaj dali 15, to odpowiednio nasze wyniki byłyby zawężone.
W ten sposób możemy się do API dobrać,
no i naturalnie nie będziemy tego robili
po to, żeby ten JSON nam został zwrócony w przeglądarce, tak jak ja tutaj robię,
tylko będziemy chcieli te dane odebrać i mając je np.
robiąc to z pomocą jakiegoś JavaScript u nas
na stronie będziemy mogli wyświetlić sobie odpowiednio nazwę, tagline, opis tego piwa i
generalnie tak, w ten sposób właśnie działa cały internet.
Część serwerowa przygotowuje dla nas tą
całą logikę i wystawia nam ją w postaci tych tzw.
endpointów, czyli przez API.
My do tych endpointów jako np.
front-end developerzy łączymy się, bierzemy dane, które chcemy,
najczęściej potrafimy w nich też wyszukiwać z pomocą
właśnie tych query stringów lub w inny sposób, a później jakoś je formatujemy i
wyświetlamy już na naszej właściwej witrynie.
Więc tych dostępnych publicznie API jest masa.
Tu jest ich jakaś przykładowa lista,
ale mamy też jakieś jak widzisz API z przepisami
i tutaj również możemy jak widzisz
sformułować sobie takie proste zapytanie gdzie dostajemy przepis po
po prostu zapytaniu ingredients czyli i, możemy tutaj podać
różne składniki, czyli możemy przykładowo podać cebulę i czosnek, onions, garlic,
pewnie możemy wpisać też mushrooms i coś takiego
i jeszcze żeby query nam pasowało do omletu
to jest chyba jakaś paginacja, ale możemy to po prostu sprawdzić w ten sposób.
I zobacz, że dostaliśmy kilka przepisów
z informacjami o tym jaki to jest omlet, z czego się składa, jakie są przepisy,
a nawet link do tego omletu i niektóre nawet mają zdjęcia.
Zobacz, że mamy obrazki, które możemy
tutaj obejrzeć i gdybyśmy robili aplikację np.
mobilną, ta aplikacja mogłaby korzystać z takiego API,
przykładowo wyświetlać przepisy a my byśmy mogli tylko dorobić logikę, która pozwala
nam jakoś fajnie te przepisy filtrować, jakoś je pokazywać itd.
Więc w ten sposób to działa
jeśli chodzi o odczytywanie danych z rozmaitych API.
Natomiast tak jak powiedziałem, wszystkie współczesne serwisy mają jakieś API
dostępne czy jest to Facebook, czy Twitter, czy Google, czy YouTube i tak
dalej, możemy dostać się do tych danych programistycznie właśnie z pomocą API,
natomiast korzystanie z nich jest już
trochę bardziej trudniejsze niż z tych np. przepisów, które Ci pokazałem
i nie możemy co do zasady tak o po prostu
wkleić sobie jakiegoś adresu, ponieważ te API są w pewien sposób zabezpieczone.
O tym porozmawiamy w kolejnej lekcji.