Szeroka Perspektywa Full-Stack Web Developmentu: Standard REST
Najważniejsze zagadnienia, które musisz znać
5 godz. 53 min · JavaScript · Full-stack i Programowanie
Adam GospodarczykCzego się nauczysz
- Protokół HTTP
- Formaty wymiany danych
- Komunikacja po stronie front-endu i back-endu
- Praktyczna praca z REST API
- Wprowadzenie do GraphQL
- Wprowadzenie do baz danych
- Zasady projektowania struktur bazodanowych
- Najczęściej popełniane błędy w komunikacji
- Autoryzacja i uwierzytelnienie
- Wstęp do bezpieczeństwa aplikacji webowych
Komunikacja w aplikacji
Przesyłanie oraz transformacja danych to jeden z najważniejszych elementów działania każdej aplikacji. Dobre zrozumienie tego w jaki sposób odbywa się ten proces, daje równocześnie lepsze zrozumienie całej struktury oraz podejmowania decyzji projektowych. W tym kursie znajdziesz lekcje, które pozwolą Ci uporządkować wiedzę na temat protokołu HTTP oraz formatów wymiany danych.
REST API i GraphQL
REST oraz GraphQL to nadal nieodłączone zagadnienia tematu wymiany informacji w kontekście aplikacji webowych. Pomimo tego, że ich koncepcje zwykle są bardzo dobrze opisane w różnych źródłach, tak ich wykorzystanie "na produkcji" potrafi sprawić problemy. W szczególności gdy weźmiemy pod uwagę, wyjątki oraz fakt, że nie każda aplikacja będzie wymagać implementacji REST czy GraphQL w 100%. W tym kursie znajdziesz wiele praktycznych wskazówek związanych z pracą z REST API oraz wprowadzenie do pracy z GraphQL.
Walidacja danych i obsługa błędów
Niektóre błędy w aplikacji są bardzo pożądane, w szczególności gdy jasno informują użytkownika o tym, co się wydarzyło oraz o tym, co może z tym zrobić. Pomimo tego, że w wielu przypadkach opracowanie komunikatów leży w rękach osoby odpowiedzialnej za copywriting (i/lub ux writing), tak sama implementacja tych komunikatów odbywa się po stronie kodu. Nie rzadko okazuje się, że poprawna i skuteczna walidacja danych oraz obsługa błędów nie jest oczywista w "produkcyjnych" sytuacjach. W tym kursie znajdziesz najczęściej spotykane problemy oraz sposoby ich rozwiązania.
Bazy danych
Bazy danych są praktycznie nieodłączną częścią każdej aplikacji. W roli full-stacka prędzej czy później przyjdzie Ci z nimi pracować a nie rzadko nawet projektować oraz rozbudowywać ich struktury. W tym kursie znajdziesz informacje o bazach danych, które pozwolą Ci je zrozumieć oraz od razu poznać użyteczne techniki, które pomogą Ci w pracy z nimi, zarówno na produkcji jak i w środowisku lokalnym czy testowym.
Autoryzacja i uwierzytelnienie
Nie wszystkie informacje w aplikacji są publiczne. Niektóre wprost nie mogą takie być. Z tego powodu niezbędne są sposoby na to aby poznać a potem weryfikować tożsamość użytkownika, by na jej podstawie przydzielać mu dostęp wyłącznie do zasobów, do których odczytywania posiada uprawnienia. Istnieje wiele technik, które umożliwiają zarządzanie dostępem do danych i w tym kursie poznasz najważniejsze z nich. Dowiesz się nie tylko w jaki sposób zabezpieczać dane ale poznasz też najpopularniejsze sposoby na to aby te zabezpieczenia łamać i obchodzić. Mając świadomość takiej możliwości, będziesz w stanie lepiej podejmować decyzje o tym jak projektować dostęp do informacji.
Popularne błędy i ich rozwiązania
Istnieją problemy charakterystyczne dla niemal każdej aplikacji. W związku z ich powszechnością, istnieje też szereg rozwiązań lub sposobów na to, aby możliwie zredukować ich następstwa. Na przestrzeni lekcji tego kursu zobaczysz wiele przykładów, które pomogą Ci w codziennej pracy a niekiedy nawet, pozwolą uniknąć błędów, których konsekwencje nie zawsze występują natychmiast.
Dla kogo jest ten kurs?
Kurs powstał z myślą o osobach, które chcą rozwijać się w roli full-stack web developera / developerki, przeprowadzając przez najważniejsze zagadnienia z obszaru wymiany, transformacji oraz przechowywania informacji w aplikacji oraz pomiędzy aplikacjami. Jeżeli potrzebujesz zobaczyć szeroką perspektywę tego, w jaki sposób dane przepływają pomiędzy różnymi częściami aplikacji, lub ugruntować swoją wiedzę na ten temat, to ten kurs jest miejscem, którego szukasz.
Nie mam żadnych wątpliwości, że termin REST API jest Ci dość dobrze znany.
Niewykluczone też, że zdarzyło Ci się już wielokrotnie korzystać z takiego API, ale
teraz, w związku z tym, że rozwija się jako full stack, musisz rozumieć nie tylko
to, jak z niego korzystać, ale również czym w ogóle jest rest API i jak działa,
jakie zasady nim kierują i kiedy możesz je naginać.
Z tego powodu w tej lekcji szeroko
przyjrzymy się temu tematowi i przejdziemy przez jego poszczególne elementy.
I teraz co ciekawe, jeżeli przejdziemy sobie do Wikipedii, to dowiemy się, że
jest to nic innego jak styl opisujący spójny interfejs pomiędzy różnymi
komponentami, zwykle występującymi w Internecie w konfiguracji klient serwer.
Aby w pełni zrozumieć tą definicję, musi
być dla Ciebie jasne, czym w ogóle jest interfejs.
Jeżeli chodzi o jego definicję jest ona bardzo złożona, a tak naprawdę chodzi o
nic innego jak sposób umożliwiający komunikację.
Zatem jeżeli wrócimy do definicji Westa,
okazuje się, że jest to styl opisujący spójny sposób wymiany informacji w
Internecie pomiędzy klientem a serwerem, czyli znaną nam już architekturą, która
jest prawdopodobnie jedną z najbardziej popularnych, o ile nie najpopularniejszą.
Zatem ujmując to jeszcze prościej REST API
to po prostu zestaw zasad, które można zastosować, aby spójnie komunikować
komponenty naszej aplikacji ze sobą, bądź też naszą aplikację z innymi aplikacjami.
W rezultacie te spójne zasady sprawiają, że wykorzystywanie REST API na przestrzeni
różnych aplikacji jest po prostu dość intuicyjne i też odpowiednio łatwe.
Jednocześnie z punktu widzenia full stack bądź osoby pracującej na backend bardzo
istotne jest, aby doskonale rozumieć zasady, które określane są przez REST API,
aby móc je nie tylko zastosować w praktyce, ale też tak jak wspomniałem w
niektórych miejscach naginać do swoich potrzeb i robić to w odpowiednim stylu.
Zacznijmy jednak od najważniejszego elementu jakim są endpoint.
No bo jeżeli mamy serwer oraz klienta, to
pomiędzy jednym a drugim dochodzi do komunikacji.
Jak wiemy już z wykorzystaniem protokołu
HTTP, gdzie wykorzystujemy właśnie endpoint oraz metody HTTP do tego aby
przesyłać informacje z klienta na serwer i z powrotem.
Jednak tutaj jeden z większych problemów
przy projektowaniu takiego API polega na tym, aby zaprojektować endpoint w taki
sposób, aby nie tylko w skuteczny sposób przenosiły informacje, ale również były
przyjazne z punktu widzenia użytkownika aplikacji, ale także developera.
Mianowicie, tak jak łatwo tutaj odgadnąć mamy zapytanie typu GET, czyli pobieranie
danych na endpoint i users z dodatkowym parametrem query spring.
Name ustawiamy na off.
Znając zasady REST API jesteśmy w stanie
dość łatwo wywnioskować, że pobieramy tutaj użytkowników, ale zawężamy tutaj
wyniki pobierania do użytkownika, którego nazwa ustawiona jest na over.
Jeżeli jednak spojrzymy sobie na kolejne przykłady, okaże się, że teoretycznie te
wszystkie endpoint mogłyby robić dokładnie to samo.
Rzecz w tym, że ich struktura znacznie się różni.
Oznacza to, że jeżeli nie mielibyśmy zasad
zdefiniowanych przez REST API, to tak naprawdę każda osoba, która traktuje swoje
API, mogłaby wymyślać swoje własne ścieżki oraz zasady komunikowania.
Coś takiego stwarza problem z punktu widzenia zwykłej użyteczności, ponieważ
wyobraź sobie, że masz do czynienia z wieloma różnymi API.
Czyli zasadniczo zwykła codzienność, a
jednocześnie każde z nich zaprojektowane jest całkowicie w inny sposób.
Wymagałoby to albo nauki każdego z nich, albo też nieustannej pracy z dokumentacją.
Oczywiście w praktyce bardzo często i tak
pracujemy z tą dokumentacją, natomiast jest to zdecydowanie łatwiejsze, niż
gdybyśmy mieli do czynienia tutaj z tak zdefiniowanym chaosem.
Zatem pierwszą i z mojego punktu widzenia najważniejszą rzeczą, którą zajmuje się
REST, jest określenie tego, w jaki sposób ma wyglądać ta komunikacja.
Inaczej mówiąc, w jaki sposób ma wyglądać interfejs.
Czyli wracamy do definicji, którą przeczytaliśmy w Wikipedii.
Tymczasem kolejnym elementem czy też zasadą rest API jest tzw.
uniform interface.
Jest to nic innego jak to, co przed chwilą
powiedziałem, czyli zapewnienie spójnej komunikacji pomiędzy serwerem a klientem.
Jednocześnie jest jeszcze jeden mały element.
No bo tak jak na ten moment wiemy, rest
API umożliwia komunikowanie się klienta z serwerem.
Jednocześnie jest w tym jeden mały element.
Mianowicie wiemy już, że REST API
umożliwia komunikację pomiędzy serwerem a klientem.
Jednak prawda jest taka, że tych klientów może być zdecydowanie więcej.
Podobnie też z resztą serwerów, które jak już wiesz, mogą być wykorzystywane np.
za pomocą mechanizmu load balance, który
będzie odpowiedzialny za przekierowanie części zapytań na inne serwery.
Najważniejsze jest jednak to, że mamy ten
centralny punkt, który dba o to, że niezależnie od tego, który klient podłącza
się do naszego serwera, ta komunikacja zawsze wygląda tak.
Albo będą bardziej precyzyjne.
Zawsze jest spójna.
Zatem kolejną zasadą, którą musisz zapamiętać w kontekście REST API jest
umożliwienie komunikacji pomiędzy różnymi komponentami bądź różnymi aplikacjami.
Wykorzystując, można powiedzieć jeden język.
Te wszystkie aplikacje po prostu
wykorzystują jedno API, aby wymieniać się danymi, które w danej chwili są potrzebne.
Następnym elementem REST API jest bardzo wyraźny podział na klienta oraz serwer.
Mianowicie pomimo faktu, że zarówno jeden
jak i drugi element są ze sobą powiązane, a w zasadzie mogą ze sobą się komunikować,
tak jednocześnie ich rozwój może odbywać się niezależnie.
Z praktycznego punktu widzenia oznacza to mniej więcej tyle, że masz aplikację
działającą po stronie serwera oraz po stronie klienta.
Teoretycznie może się wydawać, że nie ma w tym nic odkrywczego.
W praktyce jednak bardzo często aplikacje
współdzielą ten cały kod, którego efektem jest między innymi to, że np.
serwer odpowiada nie tylko za przetwarzanie informacji, ale też np.
za przygotowanie widoków, które są przesyłane do klienta w formie kodu HTML.
Oczywiście teoretycznie nie ma w tym nic złego, a poza tym istnieją np.
takowe frameworki, które naruszają tę zasadę, ponieważ umożliwiają rozwój
aplikacji zarówno po stronie klienta, jak i serwera jednocześnie.
Jednocześnie nawet w przypadku takich frameworków.
Dość wyraźnie zarysowana jest granica pomiędzy jednym a drugim.
W każdym razie jeżeli chodzi o tą zasadę,
najważniejsze jest to, aby było dla Ciebie jasne, że serwer oraz klient powinny być
zaprojektowane w taki sposób, aby móc rozwijać się w miarę niezależnie.
Oznacza to, że jeżeli prowadzisz zmiany na serwerze, to na przykład jeżeli z tego
serwera korzystało by wiele różnych klientów, to tak naprawdę zmiany, które
zostaną tutaj wprowadzone nie powinny w żaden sposób wpłynąć na klienta.
Dopiero w momencie, gdy klient zostanie
zmodyfikowany, będzie w stanie dostosować się do nowych zmian, bądź też
zinterpretować je w jakiś specyficzny dla siebie sposób.
Ale jednocześnie ta modyfikacja nie
powinna odbywać się tak, aby serwer miał z tym jakikolwiek problem.
Mam nadzieję, że ten podział jest dla Ciebie jasny.
Tym bardziej, że wielokrotnie będziemy go bardzo wyraźnie zaznaczać.
Następną w kolejności zasadą jest states.
Mówi ona o tym, że każda interakcja, czyli
zapytanie oraz odpowiedź jest od siebie niezależna.
Oznacza to, że jeżeli klient wysyła jedno zapytanie i otrzymuje odpowiedź, to w
momencie, gdy robi to po raz kolejny, musi np.
z pomocą nagłówka Auto Dizajn ponownie
przedstawić się serwerowi, która na tej podstawie zidentyfikuje klienta i
przygotuje dla niego odpowiedni zestaw odpowiedzi.
Alternatywą dla takiego systemu
komunikacji jest przechowywanie informacji na temat sesji po stronie serwera.
W takiej sytuacji to serwer identyfikował
klienta w momencie nawiązania połączenia i utrzymywał informację na temat tego
klienta do czasu, gdy połączenie zostało zamknięte.
W tej sytuacji wygląda to tak, że mamy
zapytanie odpowiedź i w zasadzie na tym kończy się komunikacja.
Jeżeli istnieje potrzeba to wysyłane jest
kolejne zapytanie, kolejna odpowiedź i kolejny raz kończymy komunikację.
Naturalnie w niektórych sytuacjach może zdarzyć się tak, że np.
klient wyśle prośbę o wykonanie jakiejś akcji do serwera, a on wyśle odpowiedź.
I znowu mamy tutaj do czynienia z końcem komunikacji.
Ale jednocześnie serwer może przygotować
takie dane, po które klient może zgłosić się ponownie w następnym zapytaniu.
Zatem jeżeli chodzi o tą zasadę musisz
wiedzieć tylko tyle, że serwer co do zasady nie przechowuje żadnych informacji
na temat klienta, tylko wszystko przesyłane jest razem z zapytaniem.
Następną zasadą, którą mamy na liście jest szablon, czyli nic innego jak możliwość
wykorzystania pamięci podręcznej w celu oszczędzania zasobów dostępnych na
serwerze i zwiększenia wydajności aplikacji.
Co ciekawe, w tym temacie dość dużą pracę
wykonuje sama konfiguracja serwera oraz to w jaki sposób działają przeglądarki.
Ale oczywiście jeżeli będziesz rozwijać
aplikację, która będzie tego wymagać, to konieczne będzie zaimplementowanie
dodatkowych mechanizmów umożliwiających np.
klientowi kontrolę tego w jaki sposób działa ta pamięć podręczna.
Na ten temat co prawda nie będziemy
już mówić zbyt wiele, ale musisz po prostu wiedzieć, że wykorzystanie mechanizmu
pamięci podręcznej jest jednym z ważniejszych mechanizmów, jeżeli chodzi o
optymalizację aplikacji oraz wzrostu jej wydajności.
No i ostatnią zasadą, o której powiemy, jest element systemu.
W pewnym sensie nawiązuje ona do tego jawnego podziału pomiędzy serwer a
klienta, ale jednocześnie chodzi o to, że jeżeli np.
klient wysyła zapytanie do serwera z
prośbą o wykonanie jakiejś operacji, a sam serwer musi skorzystać z zewnętrznych
usług, to klient nie musi do końca o tym wiedzieć.
Oczywiście może w jakiś sposób wpływać na zachowanie serwera, aby wysłał np.
konkretną informację do usługi mail czy też zupełnie innej aplikacji, ale
jednocześnie to już w jaki sposób odbędzie się ta komunikacja zależy już wyłącznie od
serwera i klient nie musi posiadać na ten temat.
Coś takiego, jak łatwo sobie wyobrazić, ułatwia całe zarządzanie naszą aplikacją,
ponieważ ponownie przygotowujemy tutaj spójny interfejs, który dba o to, aby
klient po prostu przekazał dane i otrzymał odpowiedź pożądanej przez siebie formie.
A to, co się dzieje na BC, gdzie tak naprawdę zdefiniowana jest już tylko tam.
Jeżeli chodzi o takie główne zasady, które
dotyczą REST API to by było na tyle, ale chciałbym jeszcze dodać, że możesz się
jeszcze spotkać z zasadą count on demand, która nam występuje stosunkowo rzadko i ja
osobiście również nie miałem okazji się z nią spotykać.
Polega ona na tym, że klient może wysłać jakiś fragment kodu z prośbą o to, aby
serwer zinterpretował ten kod i wysłało np.
sam rezultat.
Myślę, że ten mechanizm jest na tyle
rzadko stosowany, że możemy go tutaj pominąć.
Najważniejsze jest dla mnie jednak to, aby
stało się dla Ciebie jasne, że REST to nic innego jak zestaw reguł, a nie żaden
standard ani też coś, czego absolutnie musisz się trzymać, tylko bardziej
kierunek, w którym warto podążać do tego, aby sprawić, że nasze API jest użyteczne
zarówno dla nas, jak i innych użytkowników.
Jednocześnie w momencie, gdy znasz tę
zasadę, będziesz w stanie też łatwiej pracować z API zewnętrznych aplikacji.
Warto tutaj jeszcze podkreślić, że ta
komunikacja odbywa się pomiędzy serwerem a klientem, ale jednocześnie nic nie stoi na
przeszkodzie, aby w niektórych sytuacjach to inny serwer grał rolę klienta i po
prostu komunikacja będzie odbywać się w tym momencie pomiędzy np.
komponentami naszej aplikacji czy też mikro serwisami, które np.
mogą stanowić integralną część całej naszej aplikacji.
Jeżeli chodzi o drugą zasadę, to chodzi tylko o to, że wiele klientów może
korzystać z tego samego języka, czy też do tego, aby komunikować się z serwerem.
Mam nadzieję, że jest to jasne.
I chodzi tutaj ponownie o przede wszystkim
ułatwienie procesu komunikacji klient serwer.
To zasada, która mówi o jasnym podziale, który ułatwia nam proces rozwijania
niezależnie serwera oraz klienta w taki sposób, aby zmiany wprowadzane po jednej
stronie nie wymagały koniecznych zmian po stronie klienta oraz odwrotnie.
Oczywiście tutaj jeszcze chciałbym dodać, że po stronie serwera mogą pojawić się np.
nowe wersje API, ale również to w jaki sposób odbywa się takie wersjonowanie.
To już jest temat na tyle zaawansowany, że
raczej nie będziemy się już na nim skupiać.
Staples to nic innego jak zasada mówiąca o tym, że serwer nie przechowuje na stałe
informacji na temat klienta i nie myl tego np.
z informacjami na temat użytkownika, tylko
na temat klienta, czyli aplikacji, która wykonuje zapytanie o określone zasoby.
Po prostu serwer za każdym razem weryfikuje np.
na podstawie nagłówka od kogo pochodzi to zapytanie i jakie dane ma zwrócić.
To zasada mówiąca o optymalizacji zapytań,
po którą również warto sięgnąć w sytuacji np.
gdy mamy do czynienia z plikami, które wykonują skomplikowane operacje, a
jednocześnie nie ma potrzeby, aby wykonywać je za każdym zapytaniem.
Wówczas serwer wykonuje pracę tylko raz, a
następnie mechanizm pamięci podręcznej przechowuje wynik danego zapytania i w
razie gdy klient pyta o dane, które znajdują się w tej pamięci podręcznej, po
prostu serwer jest wtedy zwolniony z wykonywania dodatkowych operacji.
No i lead system to nic innego jak sposób na radzenie sobie ze złożonością
aplikacji, która korzysta z wielu różnych usług, a jednocześnie klient nie ma o tym
zielonego pojęcia, ponieważ wystarczy mu API, które umożliwi mu przesłanie
zapytania na serwer oraz otrzymanie odpowiedzi w pożądanej formie.
Mam nadzieję, że to wszystko jest dla Ciebie jasne.
Jest to odrobina teorii, którą myślę, że warto znać, ale jednocześnie najważniejsze
jest to, aby zrozumieć w jaki sposób można projektować end pointy i w jaki sposób
rozwijać je wraz z rozwojem naszej aplikacji.
Teraz dzięki za uwagę i do usłyszenia za chwilę.