Pracownia Programowania

HTTP

HTTP (Hyper Transfer Protocol) jest protokołem odpowiedzialnym za przesyłanie w Internecie stron WWW.

W zapytaniach HTTP możemy wyróżnić dwa elementy: nagłówek i ciało.

Nagłówek

Nagłówki HTTP spotkamy zarówno w zapytaniach, jak i w odpowiedziach. Są one pierwszymy liniami, oddzielone od ciała jedną pustą linią. Nagłówki są opcjonalne – protokół nie wymaga ich obecności. Nagłówki to pewnego rodzaju metadane i polecenia wymieniane przez przeglądarkę i serwer – mogą się w nich znaleźć informacje takie jak rodzaj przesyłanych treści (np. czy jest to obrazek czy plik JSON), sugestia dotycząca traktowania zawartości (czy przeglądarka ma wyświetlić daną treść, czy np. potraktować to jako pobieranie), jaki jest rozmiar przesyłanych danych, kiedy były modyfikowane, jakiego rodzaju odpowiedzi druga strona się spodziewa itp.

Nagłówki przyjmują postać klucz-wartość, zapisywane w postaci:

Klucz: wartość

Przykłady:

Ciało

Ciało wiadomości przechowuje rzeczywiste dane żądania HTTP (takie jak dane formularza, etc.) i dane odpowiedzi HTTP z serwera ( pliki, obrazki, JSON, etc.).

Jeśli komunikat HTTP zawiera treść, to w wiadomości znajdują się zazwyczaj linie nagłówka opisującej treść. W szczególności:

Content-Type: nagłówek dostarcza typ danych MIME w wiadomości takich jak text/html lub image/gif.

Content-Length: nagłówek podaje liczbę bajtów w treści.

Parametry

Istnieją dwie podstawowe metody przekazania parametrów:

jako element URL przy użyciu metody GET

jako treść elementu ciała (body) żądania przy użyciu metody POST

Parametry przekazywane metodą GET umieszczane są w adresie strony po znaku ? i rozdzielone znakiem &. Parametry są zwykle przekazywane w postaci par nazwa=wartość.

Przykład:

https://www.google.pl/search?q=get+method+example&lr=lang_pl

Status odpowiedzi

Jednym z elementów protokołu HTTP są kody odpowiedzi, zwanymi też statusami. To numeryczne, trzycyfrowe kody, które są dołączane do odpowiedzi i sygnalizują status odpowiedzi.

Nagłówki grupują się względem pierwszej cyfry w sekcje:

1xx – informacyjne, nieczęsto można spotkać, dotyczą bardziej środowiska niż samej aplikacji (np. 111 – serwer odrzucił połaczenie)

2xx – zapytanie się powiodło

3xx – przekierowanie, zapytanie należy kierować pod inny adres / serwer

4xx – błąd aplikacji spowodowany działaniem użytkownika (np. wspomniany 404 – nie znaleziono – czy 403 – brak dostępu lub 400 – niepoprawnie zapytanie)

5xx – błąd serwera (np. nieobsłużony wyjątek w Javie)

Najczęstszymi statusami HTTP, z którymi możemy się spotkać są:

200 - OK, 201 - Created, 202 - Accepted

400 – Złe zapytanie (Brakuje w zapytaniu wymaganych parametrów lub nie może być poprawnie odczytane)

401 – Nie powiodła się autentykacja, brak pozwolenia

403 – Dostęp zabroniony

404 – Nie znaleziono

405 – Niedozwolona metoda (Np. wysłanie pod dany adres metody POST, a nie GET)

500 – Błąd serwera

503 – Serwis niedostępny

Lista wszystkich nagłówków HTTP dostępna jest tutaj:

https://pl.wikipedia.org/wiki/Kod_odpowiedzi_HTTP

Metody

Porównajmy metody HTTP z typowymi operacjami CRUD (create, read, update, delete):

* metoda POST jest używana do tworzenia nowych rzeczy, to praktycznie odpowiednik Create z terminologii CRUD;

* GET stanowi proste zapytanie z parametrami (odpowiednik Read);

* metoda PUT aktualizuje lub zamienia dane, można ją traktować jako update/replace into z SQL lub Update z CRUD;

* nazwa metody DELETE mówi sama za siebie i jest oczywiście odpowiednikiem Delete z CRUD.

Protokół HTTP jest bezstanowy, tzn nie ‚przechowuje’ informacji o tym, co działo się wcześniej. Jest to oczywisty problem w większości przypadków, kiedy korzystamy z narzędzi wymagających zalogowania się – informacja o tym, jaki użytkownik jest zalogowany musi być przechowywana w jakiś sposób.

Rozwiązaniem stosowanym obecnie na szeroka skalę są tzw. ciasteczka – pierwotnie mające postać plików tekstowych w formacie klucz=wartość, obecnie przechowywane w wewnętrznej bazie danych przeglądarki.

REST

REST oznacza głównie komunikację przez HTTP z użyciem kilku metod tegoż HTTP i wymianę danych w formacie JSON lub XML.

Najważniejszą własnością RESTa są zasoby. Każdy zasób ma swój adres. Adres jest unikalny i zawsze ten sam. Nie może być dwóch zasobów pod tym samym adresem. Jeden zasób nie powinien też pojawiać się pod kilkoma adresami. Przykład /student.

Przykład:

Wprawdzie REST nie wymusza użycia HTTP, ale prawie zawsze idzie z nim w parze. HTTP to coś więcej niż znane wszystkim GET i POST. Mamy nagłówki żądania i odpowiedzi, mamy kody odpowiedzi, mamy też kilka różnych metod wywołania. REST stara się wykorzystać wszystkie te możliwości do maksimum.

Uwagi:

* POST jest z kilku względów wyjątkową metodą HTTP z punktu widzenia REST. Najpopularniejsze jej zastosowanie to dodanie zasobu do kolekcji. Co ważne, identyfikator takim zasobom nadaje serwer, a co za tym idzie, klient musi mieć możliwość przenawigowania do dodanego przez siebie zasobu. Dlatego jeśli żądanie przejdzie poprawnie walidację i zasób zostaje utworzony, to serwer musi zwrócić kod 201 / Created z adresem URI nowo utworzonego zasobu zamieszczonym w nagłówku Location.

* PUT służy także do dodawania zasobów. Różnica polega na tym, że żądanie PUT musi być idempotentne. Operacje idempotentne (w algebrze) to takie, które wielokrotnie stosowane nie zmienią wyniku. Zatem jedyną możliwość idempotentnego dodania zasobu jest wstawienie go pod Id nadany przez klienta. Każdy kolejny, taki sam request będzie traktowany jako aktualizacja zasobu znajdującego się pod wskazanym Id.

Konsekwencja jest taka, że jeżeli metodę PUT wywołamy 100 razy z takimi samymi nagłówkami i body, to w bazie danych będzie cały czas jeden zasób, natomiast w przypadku dodawania przez POST utworzyć się powinno 100 zasobów z różnymi Id.

* Jeśli chcemy dobrze RESTować to adres zasobu się nie zmienia niezależnie od formatu. Różne formaty uzyskujemy wysyłając jako klient nagłówki z różnymi Content-Type.

Postman

Postman został stworzony do wsparcia wszystkich aspektów rozwoju API. Postman jest aplikacją, która pozwala na przesyłanie requestów i odbieranie odpowiedzi od serwisów internetowych.

Jak zainstalować Postmana?

https://www.getpostman.com/docs/postman/launching_postman/installation_and_updates

Po lewej stronie mamy historię wykorzystywanych zapytań, po prawej wprowadzamy szczegóły zapytania. W dolnej części pokazywana jest odpowiedź od serwera.

Metoda GET służy do pobierania danych. W polu obok (URL) wpisujemy adres metody, do której się odwołujemy.

Zadanie

Uruchom tomcata wybierając w katalogu bin

./catalina.sh run

Na windows

catalina run

Jeżeli nasza aplikacja zwróci jakiś błąd to zobaczymy go w oknie terminala.

Pobierz plik war

http://mw.home.amu.edu.pl/zajecia/PRA2017/spring-1.0-SNAPSHOT.war

i wgraj do Tomcata.

Utworzony serwis zapisuje dane o produktach (product). Serwis korzysta z bazy danych HSQL (przechowywanej w pamięci) więc każde uruchomienie serwisu tworzy nową bazę danych w pamięci.

Zadanie

Wgraj ściągnięty plik do katalogu webapps Tomcata. Odczekaj chwilę (zobacz w logach kiedy aplikacja się "załaduje").

Sprawdź czy aplikacja działa wchodząc na managera aplikacji, oraz na

http://localhost:8080/spring-1.0-SNAPSHOT/

Powinieneś zobaczyć pustą stronę (ale nie błąd 404 HTTP). Sprawdź w logach (terminalu z Tomcatem) czy nie ma też żadnych błędów.

Zadanie

Otwórz Postmana

Nasz serwis posiada metodę do generowania danych.

Spróbuj wejśc przeglądarką na adres:

http://localhost:8080/spring-1.0-SNAPSHOT/generateModel

Przeglądarka wysyła zapytanie typu GET do serwisu. Porównaj wynik z wynikiem zapytania w Postmanie. Wpisz adres w oknie adresu w Postmanie wybierz metodę GET. Wciśnij Send.

Jak widzimy żądanie nie jest "znane" a to dlatego, że zaprogramowaliśmy nasz skrypt tak by uruchamiał się poprzez wykonanie zapytania typu POST.

Zadanie

Skrypt do generowania danych wywoływany jest poprzez zapytanie POST. Zmień typ zapytania z GET na POST.

Zadanie

Wywołaj zapytanie GET na scieżce /api/products aby odczytać wszystkie produkty

Zadanie

Podejrzyj konretny pojedynczy produkt poprzez podanie URL w ścieżce /api/product/1 oraz /api/product poprzez podanie parametru (Params) id równego 1. Zobacz co stanie się gdy podasz złe parametry (spójrz także w logi Tomcata w takim wypadku).

Okienko do wpisywania parametrów pojawi się po wybraniu Params.

Zwróć uwagę na postać linka w drugim przypadki (parametr sam dodaje się do linka).

Zadanie

Dodaj produkt wywołaniem metodu post na /api/product przekazując w body JSON'a. Element dodajemy jako body zapytania http. Zmień przy tym typ przekazywanych danych na JSON. Status 201 w odpowiedzi mowi nam, że się udało. Wylistuj wszystkie obiekty, aby potwierdzić, że się udało.

Zadanie

Wykonaj zapytanie PUT na /api/product, przekazując w Body JSON'a aby wyedytować Jajko na Jajko Eko i zmienić mu cenę na 22.5.

Sprawdź na liście wszystkich produktów, czy się powiodło.

Zadanie

Wykonaj zapytanie DELETE na /api/product/1.

Uwaga! Po usunięciu serwer automatycznie przekierowuje nas do widoku listy wszystkich produktów.

Wykorzystano materiały z:

https://www.itmagination.com/pl/booster/basic-testing-of-rest-api-using-postman

https://mickl.net/2016/10/10/8-rzeczy-ktore-warto-wiedziec-projektujac-rest-owe-api/

http://www.moseleians.co.uk/wp-content/uploads/cmdm/9632/1422444257_api-restowe-whitepaper.pdf

https://kobietydokodu.pl/niezbednik-juniora-protokol-http/

http://threats.pl/bezpieczenstwo-aplikacji-internetowych/absolutne-podstawy

http://adam.wroclaw.pl/2014/07/restful-api-jak-zrobic-je-dobrze/

https://github.com/callicoder/spring-boot-mysql-rest-api-tutorial