Warsztaty Webowe grupa średniozaawansowana
Jak wszyscy dobrze wiemy wiele dziedzin szczególnie informatycznych może być rozwijanych równolegle przed różne osoby/firmy itp. Przykładowo przez to, że na świecie są różne języki nie dogadamy się mówiąc po polsku z np. Japończykiem, oraz ładowarką do Iphona nie podładujemy naszego LG-ka (a przynajmniej tak mi się wydaje). I po to aby nie było bajzlu w kwestiach stron internetowych powstał pewien standard, czyli zadady wg których klienci czyli np. użytkownicy komputerów (a bardziej nawet same przeglądarki internetowe z których korzystają) współpracują z serwerami
Ok, to był najogólniejszy wstęp jaki można było zrobić. Ale czego dokładnie dotyczą te standardy? Żeby na to pytanie odpowiedzieć trzeba najpierw zrozumieć jak działa współpraca klient - serwer. Wygląda to mniej więcej tak - klient wysyła do serwera żądanie. Czego ten roszczeniowiec się domaga? Szeroko rozumianych zasobów czyli obrazków (np. memów), stron internetowych, czy kodu JavaScript
Rolą naszego HTTP jest określenie sposobu w jaki klient może dostać się do zasobu. Każdy zasób ma swoje id, które nazywamy URI (ang. Uniform Resource Identifier)
Protokół HTTP dokładnie określa format komunikacji pomiędzy klientami i serwerami. Komunikacja ta oparta jest na wspomnianych już żądaniach i odpowiedziach. Protokół HTTP określa format tych wiadomości.
Protokół HTTP jest bezstanowy. Oznacza to tyle, że każde zapytanie może być interpretowane w oderwaniu od pozostałych.
Ktoś kto wcześniej nie interesował się i nie wie nic o protokołach mógł sobie pomyśleć - co on gada o jakimś URI, to nie był czasem URL? Literówka jak zwykle? Otóż nie tym razem. Aczkolwiek te 2 pojęcia są silnie ze sobą powiązane. URL (ang. Uniform Resource Locator) jest podzbiorem URI. URI trktujemy jako zwykłe ID, nie wgłębiając się w znaczenie poszczególnych znaków - po prostu ma być unikalny i tyle. URL jest przydatniejszy, bo zawiera też informację o "miejscu" w jakim znajduje się dany zasób.
Adres URL ma postać:
scheme:[//[user[:password]@]host[:port]][/path][?query][#fragment]
Przykładowy adres URL może wyglądać następująco:
http://szumimajster:tajne@www.warsztatysealcode.pl:80/nie/ma/tej?strony=1#identyfikator
Rozkładając to na czynniki pierwsze i wyjaśniając:
| Część adresu | Przykładowa wartość |
|---|---|
| scheme | http |
| user | szumimajster |
| password | tajne |
| host | www.warsztatysealcode.pl |
| port | 80 |
| /path | /nie/ma/tej |
| ?query | ?strony=1 |
| #fragment | #identyfikator |
W praktyce ta część adresu używana jest do określenia protokołu, najczęściej zobaczysz tu http czy https. W uproszczeniu można powiedzieć, że HTTPS (ang. Hypertext Transfer Protocol Secure) jest rozszerzeniem protokołu HTTP. To rozszerzenie pozwala na szyfrowanie połączenia pomiędzy klientem a serwerem.
user:password służą do uwierzytelniania. Uwierzytelnianie to proces, który polega na udowodnieniu, że klient wysyłający dane żądanie jest tym za kogo się podaje. Mechanizmu uwierzytelniania używasz praktycznie w każdym serwisie gdzie masz założone konto.
W tym przypadku nazwa użytkownika i hasło przesyłane są jako część URL. Nie jest to bezpieczne w przypadku używania protokołu HTTP. Nawet przy komunikacji protokołem HTTPS adres URL może być zapamiętany przez przeglądarkę. Daje to możliwość przechwycenia nazwy użytkownika i hasła. W związku z tym nie jest to bezpieczny sposób na przesyłanie hasła czy nazwy użytkownika i należy go unikać.
W przypadku protokołu HTTP sprowadza się to do nazwy domeny internetowej lub adresu IP.
Port to numer. Numer ten jest wykorzystywany przez serwer. Serwer nasłuchuje ruch na danym porcie. To tak jak z numerem w bloku, domena do numer klatki a port to numer mieszkania
Protokoły mają swoje standardowe porty. Na przykład standardowym portem protokołu HTTP jest 80. Protokół HTTPS natomiast używa portu 443. W praktyce, ze względu na domyślne wartości, porty te często się pomija. Odpowiednia wartość pola scheme pozwala na określenie czy użytkownikowi chodzi o port 80 czy 443.
Możesz także uruchomić serwer, który nasłuchuje na innym porcie. Przykładem może tu być Tomcat, który domyślnie uruchamia się na porcie 8080. W takim przypadku podanie portu jest konieczne.
path i querypath to oczywiście ścieżka do zasobu, a query to dodatkowe dane identyfikujące zasób
#fragmentOstatnia część adresu URL. W praktyce wykorzystywana jest do określenia fragmentu strony HTML (a konkretnie do el. o danym ID znajdującym się na stronie), która powinna zostać pokazana użytkownikowi.
Link do pobrania: https://curl.haxx.se/download.html
Tutorial do instalacji: https://www.youtube.com/watch?v=qlTVMuONazs
Zobaczmy działanie curla na przykładzie, wpiszcie do konsoli:
curl -v https://api.github.com/users/MikolajSzumigalski
Szczególnie będzie nas interesować część po "gwiazdkach"
Postmana można ściągnąć stąd. Będziemy go testować podobnie jak poprzedni przykład, ale bardziej go omówimy na żywo
Można go ściągnąć, ale my go pokażemy w wersji online https://httpie.org/run
Specyfikacja HTTP definiuje 8 czasowników. Każdy z tych czasowników powiązany jest z żądaniem wysyłanym przez klienta. Każde z żądań ma swoje zastosowania.
Jest to podstawowe żądanie. Każde otworzenie strony internetowej zaczyna się od zapytania typu GET. Przeglądarka wysyła żądanie typu GET żeby otworzyć stronę internetową. Specyfikacja mówi, że żądanie to służy do pobrania aktualnej reprezentacji zasobu. W praktyce może to oznaczać pobranie aktualnej wersji strony znajdującej się pod danym adresem. Zakłada się, że żądania typu GET nie posiadają dołączonego ciała wiadomości.
Zapytanie typu HEAD jest podobne do GET. Różni się jednym ważnym szczegółem. W przypadku tego zapytania odpowiedź serwera nie może zawierać ciała wiadomości. Zapytania tego typu są używane do sprawdzenia czy dany zasób się zmienił, czy do sprawdzania poprawności odnośników. Zysk z używania tego zapytania polega na tym, że ciało wiadomości nie jest przesyłane. Wyobraź sobie plik PDF, który zawiera 10MB danych. Można wysłać zapytanie typu HEAD, żeby sprawdzić czy zawartość tego pliku uległa zmianie. To czy plik jest nowszy można określić na podstawie nagłówków, które będą dołączone do odpowiedzi.
Specyfikacja mówi, że żądania typu POST są przetwarzane przez serwer zgodnie z założeniami dla danego zasobu. Taki skomplikowany opis sprowadza się do:
W codziennym użytkowaniu żądania typu PUT służą do aktualizacji danego zasobu. Zgodnie ze specyfikacją ciało wiadomości powinno posłużyć do ustawienia stanu zasobu na serwerze. Zatem w przypadku gdy zasób nie istniał żądanie tego typu powinno go utworzyć. Jeśli zasób istnieje wówczas jego stan powinien być ustawiony na ten przekazany w ciele wiadomości.
W większości znanych mi przypadków ten pierwszy aspekt jest pomijany, prawdopodobnie dla uproszczenia logiki aplikacji.
Główna różnica pomiędzy zapytaniami POST i PUT polega na sposobie interpretowania ciała wiadomości. W przypadku zapytania typu POST to zasób decyduje jak przetworzyć otrzymaną wiadomość. W przypadku żądania typu PUT otrzymana wiadomość powinna posłużyć do ustawienia wartość zasobu.
Zapytania tego typu służą do usuwania zasobów. Na przykład w którymś z wcześniejszych zapytań dany zasób może być utworzony przy pomocy żądania typu POST. Następnie może on być usunięty przy pomocy DELETE. Odpowiedzi na żądania tego typu nie powinny zawierać ciała wiadomości.
Nagłówki wykorzystywane są do przesyłania metadanych na temat zasobów. Mogą zawierać na przykład informacje o formacie, statusie odpowiedzi czy dacie. Więcej o nich (z przykładami) przeczytacie w artykule podlinkowanym na samym dole zajęć
REST (ang. Representational State Transfer) jest wzorcem narzucającym dobre praktyki tworzenia architektury aplikacji rozproszonych. RESTful Webservices (inaczej RESTful web API) jest usługą sieciową zaimplementowaną na bazie protokołu HTTP i głównych zasad wzorca REST.
Na potrzeby warsztatów, utworzone zostało KWAS_API, specjalne API do przechowywania linków do szeroko pojętych internetowych 'kwasów' (memów). Dokumentacjia API jest dostępna pod adresem: https://github.com/Stanislaw-Golebiewski/warsztaty_lato_2018/tree/master/zaj_8/API
Url oraz port które są potrzebne by połączyć sie z API zostaną podane na zajęciach, jeśli jednak ktoś chciałby je uzyskać poza zajęciami (np. z powodu nieobecności) niech skontaktuje się z jednym z prowadzących. (Stanisław: stanislaw.golebiewski@sealcode.org lub stagol@st.amu.edu.pl)
Przy pomocy dowolnego narzędzia wyślij odpowiednie zapytanie HTTP do KWAS_API by uzyskać listę wszystkich dodanych kwasów. Następnie przy pomocy kolejnego zapytania pozyskaj listę tych kwasów które dodał użytkownik o nicku "Kociamber", z tagiem "yt"
Masz swojego ulubionego mema? Podziel się nim ze wszystkimi! Przy pomocy dowolnego narzędzia wyślij odpowiednie zapytanie HTTP do KWAS_API które doda nowy zasób, po dodaniu sprawdź jakie id uzyskał.
Do wysyłania zapytań HTTP w następnych zadaniach użyjemy klienta HTTP axios. Zachecamy do przejrzenia przykładów na stronie repozytorium (https://github.com/axios/axios).
Napisz prostą stonę zawierającą przycisk. Po wciśnięciu przycisku w konsoli (console.log()) powinien pojawić log z zawartością odpowiedzi na zapytanie HTTP GET /api/v1/kwasy do KWAS_API
Ulepsz stronę tak by po wciśnięciu przycisku na stronie pojawiła sie lista linków do wszystkich kwasów pozyskanych z KWAS_API Po ponownym wciśnięciu przycisku lista powinna się odświerzyć.
Dodaj do strony okienko inputu do którego można wpisać id kwasu który nas interesuje, po wciśnięciu przycisku na stronie powinien wyświetlic się tylko ten jeden kwas, lub informacja o braku takiego id w bazie.
Napisz interface do KWAS_API w postaci strony która pośredniczy w dodaniu nowego kwasu, stona:
Sources:
http://www.samouczekprogramisty.pl/protokol-http/
http://yarpo.pl/2012/07/29/rest-ciekawszy-sposob-na-komunikacje-client-server/
https://www.youtube.com/watch?time_continue=2&v=P9b8-BrWdYs