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.
Tak jak wspomniałem, prawie wszystko ma teraz API, do którego możemy się dostać.
No i dość atrakcyjnym byłoby się dostać np.
do API jakiegoś YouTube'a, Facebooka, Instagrama czy jakiegoś innego
i oczywiście jest to możliwe.
Natomiast nie jest aż tak proste jak w
poprzedniej lekcji, gdzie korzystaliśmy z prostych API, które w zasadzie pewnie były
ograniczone ilością tych request, tych zapytań,
nie wiem, może po adresie IP czy w jakikolwiek inny sposób nas mogły
blokować, jeżeli byśmy robili tego za dużo.
W przypadku tych popularnych serwisów takich jak np.
Twitter będziemy ograniczeni, będziemy
musieli w pewien sposób zautoryzować się zanim się dostaniemy do takiego API.
Ta autoryzacja może przebiegać na różne sposoby.
I takim podstawowym pierwszym sposobem jest ta Basic Authorization, czyli Basic Auth,
która polega na podaniu naszej nazwy użytkownika i hasła
praktycznie w każdym zapytaniu, które leci do takiego API
i dopiero jeżeli Twitter uzna, że ok jesteśmy
zautoryzowani, może nam zwrócić rezultaty.
Dlaczego tak w ogóle jest?
Dlatego, że czas serwerowy kosztuje.
Procesy, które wykonują się na serwerze, czyli to oddawanie nam danych w zamian za
nasze zapytanie, po prostu kosztuje pieniądze.
Dlatego jeżeli te serwisy miałyby otwarte
swoje API, to tak naprawdę mogłyby generować duże straty.
Jeżeli ludzie mogliby je spamować, mogliby
wysyłać masowe jakieś request zawieszając te serwisy itd.
Więc na ogół jest to w pewien sposób
ograniczone, albo po prostu za dostęp do API musimy zwyczajnie zapłacić.
Tak jest w przypadku Google Maps, gdzie
jeżeli chcemy przetwarzać jakąś dużą ilość danych i wyświetlać dużo danych, gdzie
robimy jakiś Uber, który korzysta z Google Maps czy aplikacji typu Yanosik, to wtedy
będziemy musieli po prostu podpiąć naszą kartę kredytową do serwisów googla i z
niej będzie ściągana odpowiednia ilość pieniędzy za te odpowiednie ilości np.
requestów, które wykonamy, za ten czas serwerowy, który Google musi dla nas
przeznaczyć. Więc będziemy musieli korzystać z tej autoryzacji.
Drugim sposobem autoryzacji oprócz tej podstawowej jest tzw.
autoryzacja z pomocą klucza API, czyli
API Key, gdzie tak naprawdę mamy tutaj kilka sposobów.
Może to być taki prosty sposób jak
przekazanie w parametrze naszego jakiegoś sekretnego klucza, ale najczęściej jest on
w takim specjalnym nagłówku, który nazywa się Authorization Header.
Czyli w nagłówku podajemy Authorization, dwukropek i podajemy jakieś swoje dane np.
secred key itd.
Kolejne schematy autoryzacji czy
tej autentykacji polegają na skorzystaniu z mechanizmów takich jak np.
oAUTH 1 czy oAUTH 2.
Być może o nich już słyszałeś.
I są to najczęściej mechanizmy, z którymi mogłeś się spotkać, jeżeli np.
rejestrowałeś się do jakiejś usługi na webie
ale robiłeś to przez Google albo przez Facebooka.
Czyli klikałeś np.
załóż konto z Facebookiem, wtedy w osobnym okienku otwierał się Facebook
i wtedy właśnie musiała zajść ta komunikacja z API Facebooka.
Czyli API Facebooka dostaje od tej strony, z której przychodzimy też taki specjalny
adres, który nazywa się callback URL, który po prostu jest adresem powrotu.
W momencie, gdy ktoś zaloguje się już w tym okienku Facebooka, żeby Facebook
wiedział, gdzie z powrotem go przekierować.
No i w przypadku autoryzacji typu oAUTH np.
wymaga to podania klucza w jedną stronę,
później wraca taki jeszcze jeden sekretny klucz itd.
Te serwisy wymieniają się informacjami.
Nie będę wchodził w szczegóły, ale pewnie
mogłeś to zauważyć, bo w momencie gdy się np.
gdzieś rejestrujesz Facebookiem widzisz,
że ten adres parę razy się zmienia, gdzieś tam następują przekierowania.
No a teraz skoro już wiesz jak to sprawdzać, będziesz mógł sobie po prostu w
zakładce Network zobaczyć co gdzie leci i jakie rzeczy są otrzymywane.
Więc wtedy tak naprawdę możemy na jednym serwisie
dzięki temu, że API drugiego jest dostępne, zarejestrować się i nie musimy
już wpisywać w tych formularzach skomplikowanych danych.
To jest tylko jeden z przykładów zastosowania API.
Natomiast tak jak wspomniałem,
najczęściej będziemy musieli, żeby dobrać się do tych informacji jako deweloperzy,
albo je sprawdzić i sami odpytywać takie serwisy jak Facebook, Google Maps
czy Instagram będziemy sami musieli założyć konto developerskie
w takim serwisie, najczęściej nie będziemy musieli płacić, jeśli to jest na potrzeby
eksperymentów, więc zakładamy konto, będziemy musieli stworzyć jakąś aplikację
i wtedy dostaniemy od tego serwisu coś takiego jak specjalne klucze i tokeny.
Tak jak w przypadku Twittera tutaj mam.
Mamy tutaj API Key, mamy API secret key czyli
jakiś sekretny mój klucz, token i Access secret token.
To sugeruje, że to jest autoryzacja z
pomocą oAUTH 1, czyli mechanizmu, który potrzebuje tych wszystkich danych.
I dopiero mając te dane będziemy mogli wykonywać zapytania do Twittera.
Teraz jak wykonywać te zapytania? Za pomocą terminala
byłoby to dość czasochłonne i kłopotliwe,
żeby za każdym razem wpisywać te wszystkie klucze w nagłówkach autoryzacji.
W związku z tym mamy sporo programów, które nam to ułatwiają.
Jedną z takiej aplikacji jest Postman.
Postman jest to takie narzędzie, które umożliwia właśnie tworzenie i wykonywanie
tych bardziej skomplikowanych zapytań
ponieważ w Postmanie możemy oprócz takiego konkretnego
zapytania, zauważ, że mam do dyspozycji GET, POST, PUT, PATCH, DELETE itd.
No i tutaj wpisujemy request URL, ale oprócz tego możemy wpisać sobie osobno parametry,
możemy też osobno wpisać dane do autoryzacji,
osobno możemy wpisać nagłówki,
tutaj wysyła nam się treść zapytania i też możemy ją wysłać np.
tak jak wysyła się formularz ze strony internetowej jako for data albo form-urlencoded.
Ale możemy też wybrać np.
opcję raw i zamiast zwykłego tekstu sformatować to JSON
i wysłać takiego JSON jako treść naszego zapytania pod konkretny adres URL.
Teraz jeśli chodzi o tą autoryzację Postman też nam to trochę upraszcza, ponieważ nie
musimy się autoryzować do każdego request do każdego zapytania,
tylko tutaj mam opcję, że będzie to
dziedziczyć inherit autoryzację z parent czyli z rodzica. Ale tym rodzicem
w przypadku Postmana są takie kolekcje, które możemy zakładać.
Czyli mogę stworzyć sobie nową kolekcję,
nadać jej nazwę Twitter i tutaj w sekcji Autoryzacja wybrać typ autoryzacji np.
oAUTH 1 jak w przypadku Twittera.
Te wszystkie rzeczy są w dokumentacji API
konkretnego API, z którego korzystasz, więc stamtąd będziesz musiał to wyciągać.
No i w sumie praca developerów w 60 procentach polega na tym, że czytają
oni tą dokumentację, siedzą na stackoverflow tylko tam 20 czy 40% to
kodowanie. Więc to wszystko dla różnych serwisów jest inaczej opisane.
Trochę inaczej się to robi i nie ma jakiejś uniwersalnej metody.
No ale są pewne standardy jak oAUTH 1 i w przypadku Twittera musiałbym tutaj po
prostu wkleić ten Consumer Key, Secret Key, Access Token itd.
I to wszystko jest już zapisane,
ja akurat mam Twitter API tutaj skonfigurowane,
gdzie mam już zapisane w tej kolekcji wszystkie dane autoryzacyjne.
Dzięki temu nie muszę się nimi przejmować
i wystarczy, że tutaj odniosę się do API Twitter i będę mógł wyszukać już jakieś
rzeczy. Teraz jak w ogóle wykminić co ja chcę stąd wyszukać?
No oczywiście będę musiał przejść do dokumentacji API albo do API reference index
i zobaczyć jak to API jest skonstruowane,
jak mogę np. wyciągać Tweets.
Przechodzę do sekcji Tweets, Post, retrieve and engage with Tweets i stąd mogę zobaczyć, że
w tym API Reference mam wszystkie metody, które będą mi służyły do wyciągania
np. jakiś tweetów albo nawet tweetowania z mojego konta.
Jeśli jestem zautoryzowany, to mogę z pomocą posta po prostu wysłać sobie tekstowo z Postmana
jakiegoś Twitta, albo mogę sobie zobaczyć statusy innych osób, przeszukać
Twittera, mogę zobaczyć jakieś ich popularne posty.
I ja stąd wyciągnąłem sobie np.
takie polecenie, które pozwoli mi
przeszukać Twitty, czyli przeszukujemy ten endpoint Tweets,
a następnie jako query zapytanie używamy nasa i chcemy posortować rezultaty
po popularnych. Wybieram polecenie send,
w tym momencie to zapytanie się wysyła.
OK, i teraz mamy informację o tym, że gdzie API Twittera jest całkiem niezłe, ponieważ
zwraca mi dokładną informację z kodem to co powinienem zrobić.
Najczęściej po prostu dostanę jakieś np. Bad Authorization albo coś takiego, a tutaj
dostaję informację, że wiesz co, pomyliłeś się z metodą,
musisz użyć albo GET albo HEAD.
Więc oczywiście POSTem nie odczytuje się danych, więc ja muszę to zmienić na GET,
no i w tym momencie jak wyślę takie zapytanie to powinienem
już, dostałem tutaj Bad Request,
zobaczymy dlaczego.
Zobaczmy nagłówki.
A bo nie mam chyba nagłówka, nie
autoryzację mam.
Aha, bo wysłałem w Body pizzę
hawajską, no to nic dziwnego.
Wybieramy polecenie send i zobacz, że
dostałem teraz dane o wszystkich popularnych postach NASY,
czyli tych ostatnich, bo akurat API Twittera np. działa w ten sposób, że mamy
różne poziomy dostępu i po to, żeby ktoś za dużo nie uzyskał
danych i żeby musiał ewentualnie zapłacić za ten czas obliczeniowy, to mamy takie
poziomy dostępu jak Standard Premium i Enterprise.
W tej wersji standard
zobacz, że mogę przeszukiwać publiczne
Twitty czy Twitty opublikowane w przeciągu siedmiu ostatnich dni
a jakaś wersja premium, za którą pewnie trzeba zapłacić
pozwala mi się cofnąć do 2006
i wersja enterprise pewnie ma jeszcze więcej zapytań itd. Ale mi spokojnie wystarczy
z ostatnich 7 dni mam najbardziej popularne
wyniki jeśli chodzi o NASA i udało mi się to uzyskać łatwo z Twittera.
Na tej samej zasadzie mam skonfigurowane np.
Google Maps, czyli przykładowo mogę wejść sobie do sekcji Google Maps.
I teraz jak zacznę sobie wpisywać tutaj zapytanie po https
do maps google com i zobacz, że już tam o parę rzeczy pytałem.
Na przykład mogę zapytać przekazując mój prywatny klucz.
Zaraz go będę musiał zresztą usunąć po tym jak nagraną lekcję,
dlatego, że ktoś mógłby się podpiąć do
mojego klucza i korzystać jakby z mojej karty, bo wydaje mi się, że Google tego wymaga,
ale mogę tylko jako parametr adresu np. podać miejsce jakieś w Warszawie, np.
Marszałkowska.
I to jest tak, jakbym wpisywał to po prostu w polu wyszukiwania w Google. Wybieram
polecenie send i powinienem dostać rezultat.
Mamy informację, że to jest w Śródmieściu i tak dalej,
w mazowieckim, mamy dane, czyli koordynaty
Latitude i Longitude, danego graficzne mogę później z tego korzystać po to, żeby
tworzyć sobie coraz to kolejne, kolejne różne ciekawe zapytania.
A jak na pewno wiesz, Google Maps posiada też szereg takich rzeczy jak np.
API Google Places, które pozwoli Ci tutaj
do tego zapytania dodać informację o tym, że np.
chcesz znaleźć jakąś fajną restaurację
sushi w okolicy jakiegoś miejsca, gdzie przekażesz jako parametry np.
latitude i longitude i ten JSON, który dostaniesz,
te informacje z serwera zwrócą Ci wszystkie potrzebne dane.
W ten właśnie sposób tworzy się aplikacja.
Myślę, że już trochę bardziej to rozumiesz, że możemy wysyłać tego typu
zapytania, otrzymywać dane i później na tych danych pracować.
Czyli w naszych aplikacjach możemy w jakiś
sposób te dane interpretować i umieszczać je w odpowiednich miejscach, np.
w aplikacji mobilnej czy przeglądarkowej, czyli na stronie internetowej.
Jak widzisz, też mamy tutaj w Postman
akurat te wszystkie zakładki, które nam znacznie ułatwiają pracę.
Zarówno wysyłanie danych, bo możemy w body np. właśnie
wysłać sobie ten plik rok, który ustalimy na JSON i zapisać jakieś dane na serwerze.
Przykładowo wysłać to zamówienie pizzy,
jak również mamy możliwość przykładowo wysłania czy wygenerowania sobie jakiegoś
takiego SNIPPETU z kodem dla różnych języków, dla JavaScriptu, dla Javy
zwykłego cURL, które moglibyśmy teraz wykonać.
No właśnie spróbujmy teraz taki cURL z tego wykonać sobie w terminalu.
Ja korzystam z Hyper i zobaczysz, że tutaj
niby to samo zapytanie, a niestety nie jesteśmy w stanie go wykonać.
Może to być z różnych powodów. Akurat tutaj nie wiem czy jego składnia jest idealna,
ale generalnie dostalibyśmy jakiś status typu unauthorize, czyli musielibyśmy
jeszcze przesłać w tych wszystkich nagłówkach dane autoryzacyjne,
a Postman załatwia to już za nas i możemy to bardzo łatwo zrobić.
W Postmanie pracują też osoby, które są testerami i testują różne aplikacje.
To jest pewne jedno z ich naturalnych środowisk pracy, gdzie mogą testować różne
API, patrzeć jak się zachowuje aplikacja, jak się zapisuje dane, odbiera itd.
i jeżeli myślałeś o tym, żeby zostać
testerem to już masz namiastkę tego jak mógłbyś pracować.
Myślę, że w tej lekcji to wszystko. Polecam
Ci ściągnąć sobie Postmana i jako zadanie domowe np.
spróbować połączyć się z API Twittera i zobaczyć najbardziej popularne posty
Elona Muska z ostatnich siedmiu dni,
albo sprawdzić jakąś fajną pizzerię w Twojej okolicy z pomocą Google Maps API
To wszystko w tej lekcji. Do usłyszenia.