HTTP i API: Wysyłanie danych do serwera
Jak działają strony i aplikacje
1 godz. 24 min · Biznes i Automatyzacje
Grzegorz RógIdea ArchitectCzego się nauczysz
- Działanie protokołu HTTP
- Konsola i przydatne polecenia
- Wysyłanie danych formularzy
- Ciasteczka i pamięć podręczna
- Wprowadzenie do API
- Popularne API i JSON
- Aplikacja Postman
Protokół HTTP
Czy 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.
Pobieranie i wysyłanie danych
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.
Cookies i dane sesji
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.
API i JSON
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!
Dla kogo jest ten kurs?
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.
OK.To teraz spróbujmy wysłać do serwera httpbin jakieś dane i będziemy korzystać z metody
POST, czyli będziemy odnosić się do tego URI post i w ten sposób jakby zasugerujemy
serwerowi, że te dane, które wysyłamy mają być gdzieś zapisane np.
do jakiejś bazy danych.
Wpiszmy telnet httpbin.org
na porcie 80, ja skopiuję sobie to, a następnie połączymy się z httpbin.
Teraz zamiast GET wpiszemy post bo wysyłamy dane i odniesiemy się tylko na razie do
tego URI post i z pomocą HTTP w wersji 1.1 będziemy chcieli coś wysłać.
Teraz wpiszemy naszego hosta, wkleję httpbin.org
i dodatkowy nagłówek, który podam to Content-Length
w ten sposób i zdefiniuje go na 10.
Będzie to 10 bajtów, czyli będę chciał przesłać 10 bajtów.
Ponieważ bajt to jest jedna litera, to mamy 1, 2, 3, 4, 5, 6, 7, 8
i jeszcze możemy dopisać dwie literki czy cyferki, żeby ta liczba się zgadzała.
Wciskam teraz return Enter i zobacz co się stało.
Dostałem od serwera odpowiedź 200 OK,
czyli moje zapytanie zostało przyjęte,
w tej odpowiedzi mam różne informacje,
nawet informację o jaki serwer mi się przedstawił, o jakiej godzinie to przyjął,
długość tej odpowiedzi to jest 251 bajtów.
Gdybyś skopiował sobie to i wkleił do jakiegoś
narzędzia, które pozwala Ci sprawdzić ilość liter, to 251 liter byłoby dokładnie
w tej zwróconej odpowiedzi, czyli 251 bajtów
a ja wysłałem 10 bajtów i zostało to przypisane do tego nagłówka data data
i zobacz, że udało nam się z powodzeniem przekazać tę informację do serwera.
Serwer nam odpowiedział, że ok,
te informacje w takiej formie do niego dotarły.
Czyli w porządku.
Udało nam się zrobić nasz pierwszy prosty post.
Ponadto moglibyśmy zrobić post, który jest w takiej formie, że wysyłamy te dane,
ale dopisujemy tutaj coś takiego, co nazywa się tzw.
query string.
Zaczynamy go od znaku zapytania, a następnie wpisujemy imię równa się
Grzegorz i możemy też podać kolejny tak zwany parametr, gdzie tutaj będziemy mieli
też klucz wartość, czyli imię Grzegorz i w tym momencie nazwisko np. Róg,
natomiast zobacz, że rozdzielamy już to znakiem &, ponieważ jeżeli w tym naszym
query stringu znajduje się więcej parametrów, to właśnie w ten sposób nie
znakiem zapytania kolejnym, ale end będziemy je tutaj rozdzielać.
Czyli wciskam teraz enter,
będę jeszcze musiał podać nazwę hosta httpbin.org
i w zasadzie dostałem tutaj 4-setkę, czyli BAD_REQUEST.
Możliwe, że
ano właśnie oczywiście nie podałem protokołu.
Czyli połączmy się jeszcze raz telnet httpbin.org
na porcie 80
teraz upewnijmy się, że wpiszemy dobre
polecenie, czyli skopiuje sobie cały post, ale też powiem, że HTTP 1.1,
następnie będę chciał podać hosta, właśnie host będzie httpbin i w tym przypadku
nie będę podawał tego nagłówka Content-Length zobaczymy co się stanie
gdy wcisnę OK return.
Zobaczy, że zostało to przez serwer odczytane poprawnie.
Mam tu znowu dwusetkę i tym razem dane nie zostały przekazane w
formie data, a zostały przekazane w formie tzw.
argumentów.
Czyli można powiedzieć, że poleciały sobie w inny sposób, ale tak naprawdę serwer też
je odczytał. I ten sposób, który Ci pokazałem, czyli właśnie tzw.
query string mogłeś wielokrotnie widzieć
go w adresie na jakiś stronach internetowych.
To jest sposób przekazywania właśnie konkretnych danych.
Serwer potrafi je odczytać i jeśli
przekazujemy coś, co nie jest jakąś bardzo skomplikowaną strukturą danych, np.
całym zamówieniem w sklepie internetowym,
to w ten sposób możemy proste dane jak najbardziej sobie przekazać.
Chyba najbardziej popularnym zastosowaniem
tego jest, wejdę przykładowo na stackoverflow, jest wyszukiwarka.
Jeśli tu wpisze jakieś zapytanie np.
test, który źle napisałem, ale zobacz, że mamy coś takiego jak search, czyli
odwołujemy się do URI seatch, a następnie dostajemy coś takiego jak ten
query string, gdzie mamy Q czyli klucz i wartość, którą wpisaliśmy.
Gdybyśmy tutaj wpisali poprawnie test to
zwróciłoby to nam właściwie wyniki i rezultaty
na zapytanie test to zapytanie się tutaj zmieniło.
Więc jak widzisz to jest bardzo prosty sposób na przekazanie danych
z tym, że taka wyszukiwarka w serwisie
stackoverflow nie wysyła danych postem, ponieważ my nie
chcemy nic zapisać, tylko chcemy te dane odczytać.
Chcemy odczytać rezultaty wyszukiwania na frazę test, więc prawdopodobnie to
zapytanie, które tutaj leci to po prostu zapytanie o dane GET.
Jak możemy to sprawdzić?
Możesz w przeglądarce wybrać prawy przycisk myszy, a następnie polecenie
Inspect, gdzie będziesz mógł przejść do narzędzi deweloperskich
i tutaj znajduje się taka zakładka jak Network.
W tej zakładce Network będziesz widział wszystkie rzeczy, które są wysyłane.
Czyli jeśli np.
wejdziesz na stackoverflow zobaczysz tutaj
wszystkie zapytania, które lecą do serwera w momencie gdy my wysyłamy taki adres.
Nie jest to tylko zapytanie o ten cały
dokument HTML, aczkolwiek możesz tutaj włączyć sobie opcję,
tutaj jest takie coś jak Doc.
Jeżeli chcesz zobaczyć jak przylatuje do nas sam ten dokument to możesz
przefiltrować to, a następnie kliknąć sobie w takie,
może zamknę konsolę,
nie jest nam potrzebna, kliknąć sobie w takie zapytanie i zobaczyć zarówno odpowiedź,
czyli taką odpowiedź jak dostaliśmy z httpbin,
czyli ten cały HTML, jak również możesz osobno podejrzeć tutaj nagłówki.
Jak widzisz tych nagłówków jest całkiem sporo, ale jednym z ważniejszych jest
informacja o tym, jaką metodą wysłaliśmy to zapytanie.
Oczywiście metodą GET.
No to spróbujmy teraz wysłać jakieś zapytanie w
wyszukiwarce o test. I okazuje się, że to zapytanie, możemy teraz na nie kliknąć
jest również wysyłane metodą GET,
również mamy dobry wynik 200.
No i w odpowiedzi dostajemy po prostu przefiltrowane wyniki wyszukiwania.
Jeśli chodzi o to jak to się dzieje, że z tego input jest przekazywany ten parametr
to bardzo proste.
Zerknij sobie na tą małą ikonkę inspekcji,
którą możesz zaznaczyć, a następnie kliknąć na wyszukiwarce.
Wtedy zostanie Ci podany
kod HTML, kod źródłowy i tego konkretnego pola input i zobacz, że
nazwa tego pola to właśnie Q, czyli w tym tutaj name mamy Q.
To znaczy, że będziemy mogli w ten sposób odnieść się do tego pola
a jak przekazujemy dane
to już będziemy musieli tutaj zobaczyć taki znacznik, który nazywa się form,
ponieważ to właśnie cały formularz w HTML zawiera różne pola input i wszystkie te
pola input, które są w formularzu zawierają się w tym znaczniku form
a form ma jedną ważną rzecz, mianowicie coś takiego jak action, czyli akcje.
To jest właśnie ten adres URI, pod który zapytanie jest wysyłane w momencie kiedy
ktoś najczęściej wciśnie jakiś guzik w formularzu.
Taki guzik przykładowo search, który tutaj
mamy ma coś takiego jak odpowiednik, nawet nie musi tego mieć, ale jeżeli w
formularzu jest przycisk to jego domyślną akcją jest wysyłanie tego formularza i ten
formularz wysyła się na ten adres URI, czyli na Search,
to jest dokładnie tak, jak się tego spodziewamy, czyli mamy tutaj
search, a dodatkowo jako parametr w query stringu
jest przekazywane tutaj to co wpisaliśmy do pola, które ma nazwę name q i w ten
sposób serwer zwraca nam tą całą odpowiedź w zakładce Network,
która treść odpowiedzi to jest cała
wygenerowana strona z wynikami wyszukiwania,
natomiast oprócz tego mamy również masę różnych nagłówków.
Spróbujmy teraz zrobić trochę inną rzecz.
Na StackOverflow wpiszemy bardzo popularne
zapytanie. Na zapytanie test otrzymujemy Status Code 200 i otrzymujemy tą stronę
z rezultatami z Query String q=test.
Jednak jeżeli wpiszemy np.
HTML albo Java to okaże się, że dostaniemy coś trochę innego.
Czyli strona wygląda inaczej.
Tak naprawdę URL też wygląda inaczej.
Zobacz, że zostaliśmy przeniesieni na
Questions tagged [java], czyli na stronę konkretnego tagu. StackOverflow
zrozumiał, że to co wpisujemy jest bardzo
popularnym tematem i że ma trochę inaczej, lepiej sformatowaną stronę wyników niż te
podstawowe wyniki wyszukiwania i przekierował nas tam.
No właśnie to, że nas przekierował powinno też być widoczne tutaj.
Jeśli rozwiniemy sobie w Network sekcję all i wszystkie zapytania do serwera, to
będziemy mogli zobaczyć, że mamy najpierw zapytanie takie standardowe z query string
q=java, ale to zapytanie jest z innym status kodem.
Ten status to jest 302, a to znaczy, że
właśnie nastąpiło na serwerze przekierowanie.
Czyli najpierw byliśmy pod tym adresem, ale on zobaczył, że
coś się stało charakterystycznego co powinno nas przekierować na inną stronę,
czyli mamy popularne zapytanie Java i
sygnalizuje nam to za pomocą statusu 302 i później już dostajemy ten właściwy
dokument dwusetką, który kieruje nas do określonego tagu.
I tutaj zbliżamy się do tematu właśnie
status kodów. Więc mamy status code, które zaczynają się od 200 do 299,
będą to status code pozytywne, czyli że
coś się udało, więc będziemy otrzymywać taką odpowiedź od serwera
wtedy kiedy wszystko jest ok, mamy tutaj na
zielono. Później mamy trzysetki. Trzysetki
są to na ogół przekierowania, czyli będziemy mieli np.
najbardziej popularne przekierowanie 301, które
jeżeli np.
kupisz nową domenę, prowadzisz bloga pod domeną x, y,z a kupisz domenę a, b, c i
chciałbyś przekierować cały ruch z domeny x, y, z w momencie gdy użytkownicy wpiszą to
w polu adresu na a, b, c wtedy skorzystasz z przekierowania 301 po to, żeby np.
zachować całą reputację tej domeny,
w kontekście pozycjonowania, indeksowania w googlu itd.
Więc jest to jedna z przekierowania, ale
oprócz tego mamy różne inne przekierowanie, np.
302 3 4 aż do 399.
Później mamy czterysetki. Czterysetki
to są błędy i nie byle jakie błędy, bo błędy klienta.
Czyli jeżeli ja bym wpisał
np adres do zasobu, który na serwerze nie istnieje,
czyli ja popełniłbym błąd.
Ja czyli mój klient przeglądarka robi
zapytanie do zasobu, który nie istnieje, czyli popełnia błąd
dostałbym Status Code 404.
To zapytanie oznacza, że to jest
najbardziej chyba popularne, co pewnie często oglądasz w sieci
404
to błąd klienta, czyli błąd adresu lub też jakikolwiek inny.
Mamy też błędy 500. I 500 i to na ogół, a raczej nie na ogół, tylko błędy serwera.
Są to błędy, które sygnalizują, że my wpisaliśmy dobry adres, odnosimy się do
poprawnego zasobu, ale coś na serwerze poszło nie tak.
Być może czasem cała strona się wywala, np.
baza danych przestaje działać i wtedy dostajemy jakiś błąd 500 czy 503 czy 501
i to jest właśnie ten błąd serwera.
Tam coś poszło nie tak,
albo backendowiec, czyli osoba, która
jest odpowiedzialna za logikę biznesową aplikacji napisała coś źle, albo na
serwerze coś grubo poszło nie tak, czyli np.
jest nieosiągalny, albo baza danych się wysypała itd.
Wtedy dostajemy 500 i te kody statusu w zasadzie są uznaniowe.
To znaczy to nie jest tak, że mamy przyjęte, że zawsze te kody statusu
działają tak samo. Zależy to znowu od osoby, która opiekuje się serwerem i back-endem
i może te kody w różny sposób może być ich mała ilość czy duża ilość mogą być
różnie opisane, różne kody mogą być zwracane w różnych sytuacjach,
no i oczywiście najczęściej nie ma setek tych kodów, tylko jest kilka tych
popularnych z 2 setek, 3 setek, 4 setek i 5 setek.
I w tej lekcji na tym chciałbym zakończyć,
ale w kolejnych będziemy jeszcze wysyłać trochę bardziej skomplikowane, ale też
trochę bardziej typowe zapytanie post do serwera.
Do usłyszenia.