Szeroka Perspektywa Full-Stack Web Developmentu: Wyjątki

0:00W tej lekcji przyjrzymy się jeszcze kilku

0:02tematom dotyczącym rest API, które warto poruszyć, a na które nie będzie już

0:06miejsca w momencie, gdy będziemy mówić o praktycznym projektowaniu i wdrażaniu API.

0:11Pierwszym z takich elementów jest coś, o

0:13czym zdarzyło mi się już wspomnieć, a mianowicie wyjątki.

0:17Chodzi o to, że pomimo tego, że REST API rekomenduje nam, abyśmy dla zasobów

0:22wykorzystywali rzeczowniki w liczbie mnogiej, czyli np.

0:25użytkownicy, to i tak czasem mogą pojawić

0:28się sytuacje, w których będzie konieczność wykorzystania czasownika, czyli np.

0:32wyszukaj. W praktyce coś takiego narusza zasady rest

0:35API, ale jednocześnie na potrzeby naszej aplikacji może być wymagane.

0:40Z tego powodu, jeżeli zajdzie taka potrzeba.

0:42Pamiętaj o tym, że naturalnie istnieje

0:45możliwość, aby naruszyć te rekomendacje jednocześnie na tyle, na ile to możliwe.

0:49Staraj się trzymać swojego API w miarę blisko zasad, na które się decydujesz.

0:55Inaczej mówiąc, w momencie, gdy nawet w

0:56dobrze zaprojektowanym REST API pojawi się jakiś niestandardowy endpoint, to tak

1:01naprawdę w tej sytuacji, o ile zachowamy odpowiednie statusy odpowiedzi i

1:06odpowiedzi, nie będzie z jego wykorzystaniem większych problemów.

1:10Pamiętaj jednak, że w momencie, gdy na coś

1:12takiego się decydujesz, może dojść do sytuacji konfliktowych.

1:15Mianowicie, jeżeli będziemy mieli zadeklarowany endpoint, który będzie

1:19wykorzystywać metodę POST, potrzebujemy tutaj przesłać rozbudowane

1:23dane, które umożliwią nam dokonanie wyszukiwania.

1:26No to w tej sytuacji wchodzimy w konflikt

1:29z endpoint, który pobiera informacje na temat użytkowników.

1:32Mianowicie jeżeli kolejność tych endpoint wyglądałaby następująco, to w momencie gdy

1:37wyślemy zapytanie na ten zasób otrzymamy błąd 404.

1:42Wynika to z faktu, że zostanie uruchomiona

1:44akcja obsługująca endpoint zdefiniowany tutaj i po prostu słowo set zostanie

1:49potraktowane tutaj jako identyfikator użytkownika.

1:52W związku z tym albo musimy upewnić się,

1:54że struktura naszych endpoint nie wchodzi w konflikt, czyli np.

1:58możemy tutaj zrobić wyszukiwanie, które

2:00umożliwi nam zdefiniowanie typu zasobu, który przeszukujemy lub też po prostu

2:04upewnić się, że kolejność jest tutaj właściwa.

2:07Według mnie to pierwsze rozwiązanie jest

2:09lepsze, ale jednocześnie jest to decyzja, którą samodzielnie musisz podjąć.

2:13Najważniejsze z tej reguły jest to, aby pamiętać o tym, że zasady REST nie są po

2:17to, aby sztywno się ich trzymać i też utrudniać sobie pracę w wielu przypadkach.

2:22W dążeniu do tego, aby być maksymalnie kompatybilnym ze standardami, ale po to,

2:26aby określać ogólną strukturę naszego API, które będzie dążyć do zachowania tej

2:31spójności, ale nie kosztem wysokiego narzutu pracy, który również będzie

2:36przekładał się potem na utrzymanie takiego API i jego rozwój.

2:39No i właśnie w ten sposób dochodzimy do

2:41drugiego wątku, który trzeba tutaj poruszyć.

2:44Czyli same decyzje projektowe.

2:46Przykładowo to czy wykorzystasz metody PUT

2:48czy POST do tworzenia nowych użytkowników również zależy tylko od Ciebie.

2:53Teoretycznie w sytuacji, gdy znany jest

2:55docelowy adres naszego tworzonego zasobu, powinniśmy wykorzystać metodę PUT i

3:00umożliwić użytkownikowi zdefiniowanie takiego zasobu.

3:03Dodatkowo musimy też podjąć decyzję, co

3:05się stanie w momencie, gdy taki zasób będzie już istniał, albo zdecydujemy się

3:10tutaj na wykorzystanie mechanizmu accept, czyli po prostu sprawdzenia czy dany wpis

3:14istnieje i jeżeli tak, to go aktualizujemy, a w przeciwnym razie

3:18tworzymy, bądź też po prostu wykorzystujemy PUT wyłącznie do tego, aby

3:21aktualizować użytkowników, a do ich tworzenia wykorzystujemy metodę POST.

3:26To oczywiście tylko jeden z wielu

3:28przykładów decyzji projektowych, które przyjdzie Ci podejmować.

3:31Z mojej strony mogę tylko powiedzieć, że za każdym razem raczej staram się trzymać

3:35tego, aby zachować rzeczy tak prostymi jak tylko możliwe, a nie prostszymi, ale też

3:40możliwie ułatwiać sobie pracę, przewidując ewentualnie dalsze kroki, które mogą

3:45wystąpić, ale niekoniecznie też wychodzę tutaj w jakąś bliżej nieokreśloną

3:49przyszłość, próbując przygotować się na ewentualności, które nigdy nie nastąpią.

3:53Inaczej mówiąc, chodzi tutaj o zachowanie zdrowego rozsądku oraz balansu pomiędzy

3:58tym, co jest tu i teraz, a tym, co będzie w przyszłości.

4:01Pamiętaj o tym, że w momencie, gdy tworzysz publiczne API, Twoje decyzje mogą

4:05wpływać potem na wiele różnych aplikacji, które będą podłączone do Twojego API.

4:09Oznacza to mniej więcej tyle, że każda

4:11kolejna decyzja, którą będziesz wprowadzać, nie będzie już zależała tylko

4:16od Ciebie, ale będzie trzeba też brać pod uwagę innych użytkowników, którzy

4:19korzystają z przygotowanego przez Ciebie interfejsu.

4:22Domyślasz się pewnie, że to, o czym mówię, nie jest prostą sztuką.

4:26Jednocześnie nie mam możliwości nauczyć

4:28się tego wszystkiego, nawet gdybyśmy spędzili tutaj wiele miesięcy.

4:32Z tego powodu w tym miejscu to na Tobie

4:33spoczywa odpowiedzialność, aby rozwijać swoje umiejętności.

4:37I w związku z tym ja mogę Ci tylko polecić jedno ze źródeł, które pamiętam, że na

4:41pewnym etapie bardzo mi pomogło właśnie przy projektowaniu API.

4:45Dodatkowo pamiętaj o tym, że oprócz rest API mamy również np.

4:49gra SQL czy inne sposoby umożliwiające komunikację.

4:52W związku z czym musisz również brać je pod uwagę i ewentualnie decydować się na

4:57nie w momencie, gdy uznasz, że jest to uzasadnione.

5:00W każdym razie, jeżeli chcesz rozwijać

5:02swoje umiejętności budowania apek, których nie będziesz nienawidzieć oraz też Twoi

5:06użytkownicy, no to mogę polecić Ci książkę, którą właśnie widzisz na ekranie.

5:11Oczywiście na ten temat powstało jeszcze

5:13wiele innych książek, do których warto zajrzeć, przynajmniej po to, aby je

5:17przekartkować i zajrzeć w przynajmniej w te obszary, które sprawiają Ci największy

5:22problem lub których potrzebujesz w danej chwili.

5:24Z pewnością jest to dobry sposób na to, aby szukać inspiracji.

5:28Tymczasem drugim sposobem jest też przeglądanie i podglądanie API innych

5:32usług, z którymi będziesz spotykać się projektując własne API.

5:37Wracając jednak do naszego tematu, kolejnym wątkiem, który chciałbym

5:40zaznaczyć raz jeszcze jest security, czyli bezpieczeństwo.

5:44Przede wszystkim musisz pamiętać o tym,

5:46aby zabezpieczyć się na wszelkie wycieki danych.

5:49Mam tutaj na myśli zarówno bardzo

5:51zaawansowane techniki, jak i te najprostsze, sprawdzające czy dane

5:55użytkownik ma dostęp do zasobów, o które prosi.

5:57Chodzi o to, że właśnie te najprostsze

5:59błędy są równie proste do tego, aby je popełnić.

6:03Jeżeli spojrzysz sobie na listę najczęściej spotykanych błędów w security,

6:07to w Top 3 znajdziesz właśnie niezabezpieczone Endpoint API.

6:11Z tego powodu uczulam Cię na to, aby sprawdzać to wielokrotnie.

6:14Tym bardziej, że tutaj wystarczy błędny warunek if czy np.

6:18jakiś błąd typu.

6:19Do tego, aby udostępnić zasoby, których nie chcesz udostępniać.

6:23Kolejnym wątkiem jest sprawdzanie uprawnień.

6:26Mam tutaj na myśli nie tylko sytuację, w

6:28którym Twoje API przewiduje poziomy uprawnień dla użytkowników, ale również

6:32sytuacje, w których tego poziomu uprawnień nie ma.

6:35Chodzi o to, że pokazywałem się sytuacje, w których użytkownik może np.

6:39zmanipulować zapytania i podmienić swój identyfikator w taki sposób, aby np.

6:45zaktualizować rekord, do którego sam nie jest przypisany.

6:48Zatem na tym etapie pamiętaj proszę, aby

6:50nie ufać danym, które przychodzą do Ciebie ze strony klienta.

6:54Czasem te dane mogą być zmanipulowane, a

6:57czasem może to być zwykła pomyłka, która może doprowadzić do dostępu do informacji,

7:01do których dany użytkownik dostępu nie powinien posiadać.

7:05Trzecim punktem jest wykorzystanie HTTPS.

7:08Mam nadzieję, że w tym przypadku nie

7:09trzeba tego podkreślać, tym bardziej, że przeglądarki bardzo mocno utrudniają już

7:14dostęp do osób, które nie są w ten sposób zabezpieczone.

7:17Natomiast i tak warto to brać pod uwagę.

7:19Poza tym, jeżeli projektujesz aplikacje

7:21oraz API, które daje dostęp do bardzo wrażliwych danych, upewnij się, że

7:26wykorzystasz też odpowiedni certyfikat SSL.

7:28W większości przypadków w zupełności wystarczy popularne krypto.

7:33Natomiast w momencie, gdy chcesz zadbać o

7:34wyższy standard bezpieczeństwa, konieczne będzie wykupienie płatnego certyfikatu.

7:39Następnym wątkiem jest right limit i

7:41trolling, czyli nic innego jak limitowanie dostępu do Twojego API.

7:46Teoretycznie może się wydawać, że taki problem może dotyczyć, ponieważ np.

7:50Twoja aplikacja jest zbyt mała na takie problemy.

7:54Okazuje się jednak, że nie do końca musi tak być, ponieważ może zdarzyć się np.

7:58, że użytkownik Twojego API przypadkowo wyśle Ci jakąś dużą liczbę zapytań.

8:03Wtedy może okazać się, że np.

8:04Twój serwer przestanie działać i ucierpią na tym wszyscy inni użytkownicy.

8:09No i jeżeli jesteśmy już przy działaniu naszego API, to wydaje mi się, że ostatnim

8:13wątkiem, które szczególnie powinniśmy brać pod uwagę jest jego stabilność.

8:18Mam tutaj na myśli wykorzystanie testów

8:20automatycznych, które po pierwsze w stopniu podstawowym przejdą przez tak

8:24zwane szczęśliwe ścieżki i sprawdzą, czy nasze API w ogóle odpowiada.

8:28Jednocześnie mamy też HEPA.

8:30Oczywiście, jednak w praktyce takie podstawowe testy to tylko początek.

8:34Warto też uwzględnić tzw.

8:36pozytywny test, czyli dodatkowe sytuacje, w których przekazywane są również

8:40opcjonalne parametry i czy są one odpowiednio respektowane.

8:44Dalej mamy testy, które uwzględniają

8:47zwracanie błędów, ale w przypadku poprawnych danych np.

8:50w momencie, gdy próbujemy zarejestrować użytkownika na to samo konto email

8:54powinien oczywiście otrzymać informację o błędzie.

8:57Takie sytuacje są dość trudne do przewidzenia ze względu na to, że dość

9:01łatwo je pominąć, a jednocześnie dość trudno na nie wpaść.

9:04Po prostu niektóre sytuacje wychodzą w praktyce, ale o tym również można nauczyć

9:09się z wielu źródeł dotyczących testowania rest API.

9:12Kolejnym wątkiem jest testowanie sytuacji,

9:14w których użytkownik wprowadza niewłaściwe dane.

9:17W takiej sytuacji również powinniśmy je

9:19odpowiednio znajdować i też w odpowiedni sposób poinformować użytkownika o tym, co

9:24dokładnie się stało i co może zrobić, aby naprawić ten problem.

9:28O tym, jak go informować już sobie

9:30mówiliśmy, a o tym, jak to robić, będziemy jeszcze mówić.

9:33A tymczasem kolejnym wątkiem, który trzeba

9:36wziąć pod uwagę jest sytuacja, w której użytkownik celowo próbuje wpisać jakieś

9:40informacje, które próbują w różny sposób uszkodzić nasz system.

9:44Co więcej, czasem takie działanie może być celowe, a czasem nie do końca np.

9:48przy wgrywaniu zbyt dużego pliku może okazać się, że nasz serwer będzie próbował

9:53go przetworzyć, o ile nie ustawimy mu odpowiednich limitów.

9:57W związku z tym na takie scenariusze również warto się przygotować.

10:00I warto brać je pod uwagę.

10:02I ostatnim wątkiem jest monitorowanie naszego API i informowanie też

10:06użytkowników o jego aktualnym statusie w formie np.

10:09strony internetowej.

10:11O tym również już mówiliśmy, a

10:13jednocześnie chciałem zwrócić na to uwagę, ponieważ jest to dość ważny aspekt.

10:17Jak widzisz, w przypadku praktycznego projektowania API jest przynajmniej

10:21kilkanaście wątków, które trzeba brać pod uwagę i niestety dość duża część z nich

10:26wymaga posiadania po prostu doświadczenia w projektowaniu API i też umiejętności

10:30odnajdywania się w niestandardowych sytuacjach.

10:33Cała wiedza, którą pozyskasz na temat projektowania API i zastosowania dobrych

10:38praktyk może przydać się w najmniej oczekiwanym momencie.

10:41Jednocześnie musisz pamiętać o tym, że czasem przyjdzie Ci podjąć decyzję, która

10:45będzie wykraczać poza ogólnie przyjęte reguły i wtedy te decyzje powinny

10:49balansować pomiędzy możliwie trzymaniem się standardów a użytecznością Twojego API

10:55oraz elementami związanymi z jego dalszym rozwojem i utrzymaniem.

10:59Mam nadzieję, że ta lekcja pomogła Ci

11:01uchwycić taki bardzo szeroki kontekst projektowania REST API oraz wątków, które

11:06musisz brać pod uwagę zarówno w momencie, gdy pracujesz z takim API oraz w

11:10szczególności gdy samodzielnie je projektujesz.

11:12W tym momencie zostawiam Cię z tymi tematami i do usłyszenia niebawem.