Wprowadzenie do REST API

Pierwszy moduł zakończył się tym, że stworzyłeś żądanie HTTP, wysłałeś je i otrzymałeś odpowiedź.

W przyszłości będziemy to robić jeszcze wiele razy. Będziemy wysyłać żądania do serwerów innych firm. Będziemy tworzyć aplikacje, które same przyjmują takie żądania i zwracają odpowiedź. Będziemy tworzyć skomplikowaną logikę przetwarzania żądań.

Dlatego dobrze byłoby dokładnie przestudiować wszystko, co związane z tymi żądaniami, przeanalizować je szczegółowo. Tak, aby nie tylko skopiować gdzieś żądanie i je powtórzyć, ale naprawdę dowiedzieć się, jak to wszystko działa.

Tym właśnie zajmiemy się w drugim module. Do dzieła!

Informacje ogólne

Zacznijmy od informacji ogólnych.

Jeśli odrobiłeś zadanie domowe z pierwszego modułu i przestudiowałeś dokumentację, powinieneś był zauważyć skrót API. Tak naprawdę to właśnie dokumentacja API jest pierwszą rzeczą, którą powinni przestudiować programiści, jeśli chcą zrozumieć interakcję z jakąś usługą lub aplikacją w sieci.

API

API - Application Programming Interface (interfejs programowania aplikacji). Jest to opis sposobów, w jaki klient i serwer mogą się ze sobą komunikować. Otwieramy dokumentację API i stamtąd dowiadujemy się, jak uzyskać potrzebne dane z serwera.

Zawsze chcemy, aby ta interakcja była prosta i zrozumiała. Upraszcza to zadanie zarówno programistom (nie trzeba wymyślać koła na nowo przy projektowaniu nowej usługi), jak i użytkownikom (usługa jest znacznie łatwiejsza do nauczenia się, jeśli działa na tej samej zasadzie, co wcześniej znane usługi). I tu warto przypomnieć sobie nowy termin - REST.

REST

REST - akronim oznaczający Representational State Transfer. Może nie brzmi to zbyt jasno, ale najprościej rzecz ujmując, REST to styl interakcji (wymiany informacji) pomiędzy klientem a serwerem.

Nie jest to jakiś sztywny zestaw reguł i wymagań. REST nie wymusza użycia żadnego konkretnego języka programowania, ani nie wiąże rąk ścisłymi wytycznymi. REST nazywany jest stylem architektonicznym i określa 6 zasad, które musi spełniać architektura systemu.

W związku z tym, API opracowane z uwzględnieniem zasad REST nazywane jest REST API, a same aplikacje - RESTful

Będziemy tworzyć właśnie takie aplikacje RESTful, więc warto od razu omówić zasady, które będą one spełniać.

Zasady RESTful

Model klient-serwer. Zasada ta określa rozdzielenie klienta i serwera, zróżnicowanie ich potrzeb. Klient nie musi się martwić o sposób przechowywania danych, najważniejsze jest, aby były one wydawane na żądanie. Z kolei serwera nie interesuje, co klient zrobi z tymi danymi, jak je dalej przetworzy i wyświetli. Dzięki temu mogą się one rozwijać niezależnie od siebie i poprawia się skalowalność systemu.

Bezstanowość. Zasada ta oznacza, że serwer nie powinien "wymyślać" odpowiedzi na podstawie wcześniejszych doświadczeń z tym klientem. Każde żądanie jest wykonywane w taki sposób, że zawiera wszystkie niezbędne informacje do jego przetworzenia, niezależnie od poprzednich żądań.

Caching. Aby zminimalizować przesyłane dane, istnieje mechanizm buforowania. Na przykład, jeśli na jakiejś stronie wyświetlane jest logo, to nie ma sensu za każdym razem żądać go od serwera. Nie zmienia się ono tak często, wystarczy pobrać je raz i zapisać na komputerze klienta, w pamięci podręcznej. Jeśli jednak potrzebujemy uzyskać informację o aktualnej prędkości samochodu, to pamięć podręczna w żaden sposób nie pomoże. Zasada ta określa, że dane przekazywane przez serwer powinny być oznaczone jako nadające się do buforowania lub nie.

Jednolity interfejs. Zasada ta określa jednolity format interakcji klient-serwer. Struktura wszystkich żądań musi być taka sama. Dane muszą być przesyłane w takiej samej formie, niezależnie od tego, kto o nie prosi.

System warstwowy. Klient i serwer nie muszą komunikować się bezpośrednio. Transmisja danych może przechodzić przez kilka węzłów pośrednich. W tym przypadku system jest tak zaprojektowany, że ani klient, ani serwer nie wiedzą, czy wchodzą w interakcję z aplikacją końcową, czy z węzłem pośrednim. Pozwala to na zrównoważenie obciążenia serwerów, zwiększenie skalowalności.

Kod na żądanie (opcjonalnie). Jedyna zasada, która nie jest obowiązkowa. Zgodnie z nią klient może rozszerzyć swoją funkcjonalność, pobierając z serwera kod wykonywalny (na przykład skrypty). W tym przypadku kod powinien być wykonywany tylko na żądanie.